772 replies to this topic

[WanWizard]

It is about abstracting all hardware (related) data from the code of Enigma and plugins, so that no code in both needs to apply logic to that data.

 

For Enigma, and for plugins, it should be 100% transparent on what hardware the software runs.

 

That mains that ANY code that applies logic to the values returned, like in the examples above, need to be converted into an API method.

 

And note, this is about API definition, not about implementation. So given the example above, the API should define:

list: BoxInfo::getSupportedVideoModes(); => Returns a list of strings containing all video modes the hardware supports. If no modes are supported, it returns an empty list

and nothing more (well, maybe a bit more documentation and/or examples),

 

How this method is implemented by each team is up to them, the only requirement is that the method is defined so code can call it and get the expected result back.

 

So this cross-team group that I think should be setup to manage the API definition should do a few things:

1. Agree on a python, C and ash shell interface, so it can be called from Python, C and ash shell
2. Agree on a name for the interface, which is needed to be able to call it
3. Agree on the way it will be implemented (for example a global singleton you call methods on, or something else)
4. Do an inventory of the current solutions already implemented, and make sure the API has corresponding methods
5. Publish the API definition so each team can migrate to it
6. Setup a governing body to maintain the API (versioning, deprecation or addtion of methods, etc), making sure the teams stay up to date

As to 1, I would suggest to not do anything special for shell access, but to make it so that a Python script can be called from an ash script that would return  the required data.

[IanSav]

Hi Persian Prince and WanWizard,

 

Have either of you read the BoxInfo.txt file that I posted?  In my opinion, it cover's the issues and data you desire precisely, if not yet completely.

 

@Persian Prince, if you look to the bottom of the file you should note that I propose API variables that return the remote control data without any of the currently required determination code.  I accept that the current OpenPLi code is more simple but that optimisation comes with the significantly fewer remote controls supported by OpenPLi.  I think the OE-Alliance structure and data, that is implemented as part of the boxbranding system, is significantly better organised and more complete.

 

The point that Huevos raises about the source of the data is also particularly significant.  While I accept that each image will want to manipulate data in their own ways I still think it is important that *ALL* images end up agreeing that a particular make and model of receiver should end up having the same list of features and capabilities on all images.  From what I understand of the various build processes the OE-Alliance generates such core data as part of it's build process but the OpenPLi system does not.

 

I would like to suggest that OpenPLi and its derivative systems explore using and expanding the current OE-Alliance remote control database.  It could/should become the master source repository for all such information with all image teams able to maintain the data for the shared benefit of all images.  I also propose that the OE-Alliance build system be adapted / adjusted to build a data file that describes all the hardware and capabilities of each brand and model of receiver.  This data file can become the input data for a revised and improved SystemInfo (or whatever) module in Enigma2 such that this core data can be directly used by *ALL* Enigma2 images.  Again the ability of add, correct and maintain this data should be enabled for all participating images.

 

I think that we are already in violent agreement yet no-one wants to make the first move.  I hope this suggestion allows us to move forward and look to prototyping some actual logic and code proposals that can be considered.

 

Regards,

Ian.

[WanWizard]

Ian,

 

You are discussing implementation, which is not relevant at all in this discussion. I am not interested in and will not force any team into accepting some form of implementation. It is up to the teams how to implement it.

 

For example, due to the differences in build method between OpenPLi and OE-A, we have no intention of implementing a long list of bitbake and shell variables. We also have a 1:N relation between MACHINE and box, while OE-A has a 1:1, so implementations can't be the same. And I assume OE-A isn't interested in ditching their boxbranding for OpenVision's implementation, or visa versa.

[IanSav]

Hi WanWizard,

 

Well I don't see this thread making any progress trying to find and deliver your totally abstract concepts.  I have tried, and tried, and tried, to get discussion and progress happening and your posts simply stifle input and discussion.

 

As I previously suggested, if you could provide some solid points and ideas to progress discussion then please do so.  Otherwise I suggest you let people make their contributions in any way they wish in a hope that all the people looking at this thread will feel invited to contribute.  When you see something you like then support it.

 

As for sourcing some of the data we discussed, as I suggested, the OE-Alliance could assist delivering a core data set that can be used by OpenPLi and its derivatives.  The OpenPLi build system does not need to be changed.  OpenPLi can take the shared data and make as much or as little use of that data as it wishes.  As I said previously, it appears that the OE-Alliance has a significantly richer data set with which to use as a starting point.  If you objection is based on getting data from, and working with, the OE-Alliance then we have a potentially insoluble situation.

 

Regards,

Ian.

[WanWizard]

Neither do I.

 

Because everyone here immediately starts about data and implementation, and the pro's and con's of what they have already made. Only PP's last post gave an indication he gets what I am on about.

 

And that includes you. I am not intrested (at this point) in "sourcing data", nor in what data others are using. Data is just data, what it exactly is, it totally irrelevant. If we want to use completely random MACHINE names, that is entirely up to us.

 

That is the point you don't get.

 

The only reason "the data" could be important, is if you want to apply logic to it. And my point is that if you want to do that, you have not understood what an abstraction layer is and should do.

[IanSav]

Hi WanWizard,

 

That is fine.  I will stop trying to encourage discussion and await something, anything, that allows this important need to get going.

 

Regards,

Ian.

[WanWizard]

That is a very sad response.

 

Tell me, am I speaking in Klingon? What is it that you don't understand? Or want to understand? Or not agree with?

[Persian Prince]

Hi WanWizard,

 

And then: no response anymore. Disappointing...

 

I am not sure what more I can add or do at this point in time.  I suggested and posted a framework of information / data that needs to be available (I'll attach the latest draft to this message).  I also provided some template code to deliver the API in Python.  That same data and code can be made available to C++ from Python via SWIG.  This same data that primes the Python data structures can be readily accessed by the shell.

 

What more is required to make this happen?  What more input is required?  What more agreement is required?  How would you like for this to proceed?

 

Regards,

Ian.

 

Ian,

 

Data looks ok although we don't need some in Open Vision but may I ask how you make this file?

 

Please share the Python/C sources maybe I could contribute or make it better.

 

@WanWizard @IanSav

 

Both of you are well known developers with great personality, I do respect both of you the same and you're both needed for enigma2 scene.

 

Ian contributed a lot in all forks and made APIs similar so I'm pretty sure we all want the same thing here.

 

I know I can contribute to PLi and all other "PLi based" enigma2 forks for having the needed variables for the tool so don't worry about the variables and what PLi has or has not, I will send the needed PRs for that matter later.

 

We should all help to make enigma2 clean and get rid of garbage code.

 

Regards,

Persian Prince

Edited by Persian Prince, 3 September 2020 - 15:01.

[WanWizard]

We should all help to make enigma2 clean and get rid of garbage code.

 

I couldn't agree more.

 

But for some reason I can't get my message across that as long as code applies logic to whatever data an abstraction layer (boxbranding or whatever it is called) returns, that code will never be portable, as we can't and shouldn't enforce image builders to return specific data.

 

I've already gave an example:

if someobject.getMachineName() == "h9twin":
    doSomething()

This will never work on OpenPLi, as we don't have a specific image for the h9twin, and we will never have.
 

So the logic should test a feature, not a specific string, and this code should be something like

if someobject.getSomeFeatureOnlyTheH9twinHas():
    doSomething()

so determining whether or not this feature exists happens INSIDE the API, not in the plugin (or Enigma) code.

 

How the returned boolean value is determined is entirely up to each individual team.

 

It could simply be nothing more than "return false", returning some value from a text file, returning some value determined by code at runtime, whatever.

 

The point is that this is not important for this discussion, the only thing important is to decide that the API needs a "getSomeFeatureOnlyTheH9twinHas" method, and documentation of what the purpose of the method is, and what it returns.
 

[WanWizard]

I think that we are already in violent agreement yet no-one wants to make the first move.  I hope this suggestion allows us to move forward and look to prototyping some actual logic and code proposals that can be considered.

 

No, we're not, as you go on about implementation, even a specific implementation (OE-A's), and as I have said many times before, we can not and will not ever implement that. And I have explained twice now why.

[IanSav]

Hi WanWizard,

 

Never mind.  This is no longer fun or rewarding.

 

Regards,

Ian.

[WanWizard]

I find that an enormously childish response, something I don't expect from you.

 

If you don't understand me, or my examples, then say so. If you don't care about a solution but want to force OE-A's solution upon everyone, then say so. If you think I am wrong, then say so. If something else bothers you, then say so.

 

In either case,  then we can move on. Now your responses come across as "do as I say or fuck you", which is not very constructive...

[IanSav]

Hi WanWizard,

 

What response would you like from me when you accuse me of advocating for something that is the *EXACT OPPOSITE* of what I have been saying all along.

 

Where have I ever advocated that we should have a system when the functionality of Enigma2 should be based in specific hardware?  Did you look at the BoxInfo.txt file I posted?  It is filled with hardware capability data.  Yes, there are some specific box name and model items but, as I stated, these are for user interface purposes.

 

For example, the hardware manufacturer name, make and model *CAN* be used to tell a user that their "GigaBlue UHD UE 4K is restarting." etc.  But you *CAN NOT* use this information to decide if the hardware has, for example, HDMI or DVI output connectors.

 

Just to be crystal clear, there is to be *NO* use made of any hardware descriptive information like manufacturer, hardware name or model in deciding any operational modes of Enigma2.  If you want to know that the box is a GigaBlue UHD UE 4K because you want to know that it has an LDC front panel, or that the box is a Zgemma H7C because it has a four digit 7 segment display then that *MUST NOT BE PERMITTED*!  The correct and only code that should be permitted is to ask, respectively, "does this box have an LCD display" or "does this box have a 4 digit 7 segment display".

 

If you prefer pseudo code then, using the data suggested in BoxInfo.txt, something like this should *NOT* permitted:

if SystemInfo.get("MachineBrand") in ("GigaBlue", "VU+"):
	initialiseDisplay()
elif SystemInfo.get("MachineBrand" in ("Zgemma",):
	initialise7Segment()
...

however, again using the data suggested in BoxInfo.txt, something like this *IS* permitted and acceptable:

if SystemInfo.get("HasDisplay"):
	initialiseDisplay()
if SystemInfo.get("Has7Segment"):
	initialise7Segment()
...

You will also note that the logic structure has been changed so that assumptions about known hardware are no longer made.  In the first pseudo code example it was assumed that because certain hardware has certain combinations of features that one feature may exclude the other (if a box has an LCD display then it can't have a 7 segment display).  The second pseudo code example shows that each hardware attribute should be evaluated in its own right.  Thus should, at any time, a box be added to the Enigma2 supported list that has both LCD and 7 segment displays the Enigma2 code would not require *ANY* changes to support this new device.

 

In case you are wondering the "initialiseLCD()" method referenced above should continue exactly the same hardware agnostic coding.  Instead of asking the make or model of the box to get the resolution of the display the appropriate hardware abstraction code should be used.  That is, something like this is *VERY* wrong:

def initialiseDisplay():
	if SystemInfo.get("MachineBrand") == "GigaBlue":
		xres = 250
		yres = 175
	elif SystemInfo.get("MachineBrand") == "VU+":
		xres = 300
		yres = 200
...

whereas something like this could be appropriate:

def initialiseDisplay():
	(xres, yres) = SystemInfo.get("DisplayResolution")
...

It should also be noted that using this hardware abstraction system not only results in more generalised code it also results in significantly smaller and easier to read code!

 

So, now that I have restated my objectives and clarified my assertions, what is your problem with what I have been advocating?

 

Regards,

Ian.

Edited by IanSav, 4 September 2020 - 05:20.

[littlesat]

The most important think you need to do here is do not think directly in code, in text files, in solutions etc.... but design (an api)... and from that design create the code. So first it is extreme abstract... just define a frame/stream/idea.... the issue here is that we directly fall into code and/or something that already exists.

It first starts with problem/need description, goal and scope. Then a brainstorm and then define the abstract solution.... we even did not get to the problem/need description here as most proggers directly start to create code.

So the first step is hete describe the problem/need....

With these steps you may find solutions out of the box...
Most important here is the scope.... do not put too much in it...

I see wanwizard is at a kind of brainstorm mode and others are straight into implementation brainstorm phase. The idea is to take a step back...

Edited by littlesat, 4 September 2020 - 06:33.

[IanSav]

Hi Littlesat,

 

Well, what is your big abstract concept?

 

Perhaps I *should* offer my suggestion in Klingon.  Even if no-one else understands it I can claim it to be a high concept layout.  My point is, if people can't relate to concept then it is useless and pointless.  Actual code and pseudo code are perfectly acceptable discussion points when you are trying to convey ideas to a group of people particularly when most of those people are coders and many do not share the same primary spoke/written language.  My examples did not use existing code or values to highlight that it was conceptual.

 

I see no problem in offering explanations in a language that should be understandable by most people here.  The language I chose is pseudo code in a Pythonic styling as that should be a common link with most people here.  If that is unacceptable I suggest you offer something to which we can all react.

 

As to your second point...

 

 

PROBLEM:

I believe the problem is that Enigma2 has too much code that deals with specific hardware to make operational decisions on how to operate.  This makes all images quite different in places where they should be similar, if not identical.  These differences require significantly more effort in maintaining the code that would otherwise be required.  Further these differences create barriers to sharing code, plugins and skins between images.

 

GOAL:

Modify Enigma2 code and coding practice to only use hardware capabilities as a trigger for code actions.  There should be no references to specific hardware in and of the common core code.  The bulk of enigma2 needs to be migrated to using function specific or hardware attribute logic rather than specific box and specific hardware based logic.  All such hardware capabilities should be sought from a central data store.  That data store should use an agreed set of hardware capability descriptors to access the information.  Every image must agree that for any given descriptor the same (or comparable) result should be returned to the core code.  This is important as the core code should produce equivalent (or similar) results for any specific hardware box using any image.  Even more importantly, more of the core code should become identical and shareable between images.

 

This is important as the pool of coders and contributors is not large and there are significant advantages in enabling all images to share more core code.  The effort of making more code shareable means that ancillary code and services, like plugins and skins etc, can be more easily shared between images.

 

SCOPE:

I suggest that the initial scope of this project be to create a common repository of all hardware attributes.  All images, developers, plugin authors etc should then adjust their core code to no longer reference specific hardware but rather use the central repository of hardware attributes.  Where practical and possible all images should try to move their code implementations to use common (identical) code to achieve the same results.  The aim should be to simplify the core Enigma2 code and potentially, by sharing code, reduce the group effort to maintain and improve this core code.

 

My previous posts have offered proposals for the hardware attribute central store together with some examples and proposed definitions of the hardware descriptors.  Those suggestions still stand and could become discussion points for delivering on this project.

 

The next and larger scope should then be to enable a move to allowing more, if not all, plugins and skins to be shared among all images.

 

 

Okay, have I now expressed my opinion is an acceptable format?  What next?

 

Regards,

Ian.

[littlesat]

PROBLEM:

I believe the problem is that Enigma2 has too much code that deals with specific hardware to make operational decisions on how to operate.  This makes all images quite different in places where they should be similar, if not identical.  These differences require significantly more effort in maintaining the code that would otherwise be required.  Further these differences create barriers to sharing code, plugins and skins between images.

This is not the problem... This is already the false start... It is too long in the first place...

 

There are already conclusions included in here... and it includes content that belows to the next phase... the 'fishbone' phase...

 

Maybe this...?

 

There is no common method to deal with different hardware within enigma-2 images.

 

Wanwizard.... I know you can improve this....

 

It should be as short as possible.... this to avoid that implementation, conclusion and emotions are already included.

Edited by littlesat, 4 September 2020 - 09:33.

[IanSav]

Hi Littlesat,

 

First of all, if that is the problem definition you wanted then why didn't you post that?  Why push me into guessing what your definition of the problem was?  Had you posted that comment earlier then discussion could have continued without all the angst.

 

Second, be very careful with language!  Concise short English phrases are NOT easy to understand by people for whom English is NOT their preferred language.  I wrote what I wrote with far more words than I consider necessary because I have been told that my wordy English responses contain enough redundant language that makes it easier for people to understand what I am trying to say.

 

For example, I know that Captain sometimes has issues following English discussions but he has commented to me that my wordy explanations are easier for him to follow.  Given that we are a multinational group I want my contributions to be inclusive and as easy as possible for all to follow.

 

I think that what you and I said are encapsulating the same issue.  Perhaps you should post more of your thoughts so that we can also respond to your interests.

 

Regards,

Ian.

[littlesat]

The Blackbelt 'masterclass'...

 

Once with have the problem defined... we might start slowly to think about a 'goal'....

And then one more important think... the scope... (and what we want to measure)...

 

This is the moment we have everything aligned... But no code is created yet...

[WanWizard]

So, now that I have restated my objectives and clarified my assertions, what is your problem with what I have been advocating?

 

Not a problem whatsoever, this is EXACTLY what I have been on about all the time.  For me wasn't clear you understood that, because you kept going on about data and your textfile (which is a data source).

 

The fact that my autism prevents be from reading between the lines and "guessing" what people mean doesn't really help in these cases, which is why I keep asking for explanations...

 

This is the moment we have everything aligned... But no code is created yet...

 

To move on, we need a representative from each team involved.

 

We need to get a common interface defined, for C and Python, where the Python solution should be workable on the commandline (to avoid needing a third interface).

 

For example, do we do in Python:

(xres, yres) = SystemInfo.get("DisplayResolution")

or

From SystemInfo import DisplayResolution
(xres, yres) = DisplayResolution()

or something else?

 

And how do we do the same in C without the misery of accessing Python data structures?

 

Once agreed, this needs to be documented in a team-neutral place (I propose a seperate github repo with wiki, to which each representative has write access), and we need to have a set of working procedures in place describing how we are going to deal with changes and versioning (as they may have a large impact on every team involved).

 

The repo can also contain the skeleton files needed to implement it in the image. The skeleton should contain all class, method and function definitions, and ideally proper documentation about what it does, what the arguments are, and what the return value is. But no logic, as that is for each team to implement (they may want to lay it on top of their existing boxbranding, they may want to return values from text files, they may want to generate the code at compile time with static values, etc).

 

Then each team has to go through their own codebase, and identify all code that needs to be moved to the abstaction layer (as per Ian's examples), and propose methods / functions for that.

 

Once we have a "version 1", each team can start implementing it. Plugin developers can check the repo / wiki for the documentation, and see what is available for them to use.

[Erik Slagter]

In defense of Wanwizard, I DO understand what he is trying to advocate and I endorse it.

 

The current way of boxbranding/boxinfo/whatever gives information to enigma, and then enigma has, still, hardware-dependent code which is invoked depending on the outcome of the information from boxbranding.

 

Something like

 

model = getmodel()

 

if model is h7 then enable_rca_the_zgemma_way()

else if model is duo4k then enable rca_the_vuplus_way()

else etc. etc.

 

This is wrong. This code should not be in enigma. Enigma should be agnostic of underlying hardware (or, for that matter, the driver interface, which SHOULD be a hardware abstraction layer by itself, but clearly isn't, because every manufacturer does it it's own way).

 

The code in enigma should be:

 

hardwareAbstraction.enable_rca()

 

And then the hardware abstraction code should search it's lists of capabilities, workarounds, quirks, etc. to find out how to do that for this model and then simply DO it.

 

@Wanwizard I think this will only get speed if we start implementing it, to show what's the concept and why it's really better that way. We don't need to do it in a big bang, we can start small and while going extend the interface. Which must of course be properly designed to start with, the basic concepts.