772 replies to this topic

[betacentauri]

The discussion gets more and more off topic.

Regarding blindscan it is maybe too late to get it fixed properly. So let it like it is or try to improve it, but this shouldn’t be our first and important goal.

We should continue with the list. Which functions are needed and should be added to the new branding?

[littlesat]

But due to the blindscan ‘syndrome’ we need it somehow... zo it isn’t that off-topic...

And actualy when defining it we should also invulde systeminfo.py... and keep it feature driven and not boxname/type/brand driven.

[Abu Baniaz]

@Abu, here is a visual example of a hack. The bottom of the tree is painted to help motorists avoid it. Was that the correct fix?

 

tree.jpg

I asked for a definition, not example.

 

So what makes this a hack or dirty hack?

https://github.com/O...332c266af99cb3a

[Huevos]

 

@Abu, here is a visual example of a hack. The bottom of the tree is painted to help motorists avoid it. Was that the correct fix?

 

tree.jpg

I asked for a definition, not example.

 

So what makes this a hack or dirty hack?

https://github.com/O...332c266af99cb3a

 

Abu, I have no idea why you want to have this discussion with me here, where we are guests, rather than in the OpenViX development team forum.

[Abu Baniaz]

Post 126 calls those PLI changes as a hack and you then said it was a dirty hack.

[Huevos]

Post 126 calls those PLI changes as a hack and you then said it was a dirty hack.

We are guests here. This is not the place to be discussing OpenViX internal matters.

Edited by Huevos, 23 July 2020 - 15:27.

[IanSav]

Hi,

 

I am still interested in working towards a comprehensive list of hardware and system related items we need to access in a unified box info system.  Do we want to continue working on this or just give up?

 

Regards,

Ian.

[foxbob]

8 pages about nothing.I would help,but I don't have enough knowledge to help.

As a user I don't care if this module is there or not.As a person who collects an image if it simplifies some things then I am for this module.

Maybe you can take a module of one of the teams as a basis and change it for OpenPli?

[WanWizard]

As a user I don't care if this module is there or not.As a person who collects an image if it simplifies some things then I am for this module.

 

Is is not visable or usable for users. It will however aid portability of plugins between different images.

 

Maybe you can take a module of one of the teams as a basis and change it for OpenPli?

 

If we wanted something PLi specific I wouldn't have started this discusson.

 

The point is that there this will become an image indepdendent abstraction layer between hardware / OS and Enigma.

[IanSav]

Hi Foxbob,

 

As WanWizard points out this is more a behinds the scenes issue.  We are trying to find a way to make more code within Enigma2 to become more common and portable between images.  This should allow more code, plugins, skins etc to be shared among all Enigma2 users.

 

I think the issue looks more political than technical.  No image has a starting point that is acceptable to all images.  OpenPLi may not have a build system that supports the design of the OE-Alliance system.

 

This is a very difficult issue but one I hope we can work through to find a good solution for everyone.

 

Regards,

Ian.

[foxbob]

Let's hope and wait.

[Frenske]

It might be a long way before this first attempt for a universal layout will actually be followed by all developers involved. Until then we can only keep our fingers crossed and hope that in due time all teams will notice the benefits when they actually have followed this path. 

[WanWizard]

I think the issue looks more political than technical.  No image has a starting point that is acceptable to all images.  OpenPLi may not have a build system that supports the design of the OE-Alliance system.

 

That is why I focus on API and not on implementation.

 

As to implementation, we need an interface that is accessible from Python, C and Bash (which is why I initially suggested a kernel module and /proc entries), and we need a unified way (Python class, C++ class) to access that interface from E2.

 

The actual implementation behind that interface is a black box, and this would allow for a different implementation in OE-A (1 machine = 1 image = 1 box) and OpenPLi (1 machine = 1 images = multiple boxes).

 

Currently we are still at the interface definition phase (not too worried about the actual method list atm), and we still need to decide on the classes.

 

I have no issue with taking OE-A as a starting point for the definition, as that woud mean a lot less effort for them.

 

I only have some issue with that python file for remotes, that doesn't belong there. Instead, the API should have getBoxImagePath(), getBoxRemotePath(), getBoxRemoteEnigmaXMLPath() and getRemoteOwifXMLPath(), to return the FQFN of the receiver and remote images, and the FQFN to the remote keymapping xml's for E2 Help and Owif. What happens with those files is not in the scope of this excercise.

[WanWizard]

It might be a long way before this first attempt for a universal layout will actually be followed by all developers involved. Until then we can only keep our fingers crossed and hope that in due time all teams will notice the benefits when they actually have followed this path. 

 

We do we need to invite to this topic? ATVcaptain? Others? So we can have their input too?

 

Huevos, can you do this?

[IanSav]

Hi WanWizard,

 

I already invited Captain here.  He took one look at the conversations and arguments and left.  I think he may still be monitoring the thread but until people want to work *together* to find a path forward I suspect he won't participate.  I also believe that Huevos is not particularly happy with the reception of his input and contributions either.  (These are my beliefs.  I hope those individuals will comment on their own thoughts and expectations.)

 

From my own point of view, I also don't think that this has been the most productive thread.

 

I also think that talking about an API or mechanism of implementation is further down the track.  Before we can talk about implementation and API type issues we need to get an understanding on the type and extent of the data we need to collect and implement that we will want to deliver via the API.  I think Betcentauri gets it but our conversation was drowned out.

 

Regards,

Ian.

[WanWizard]

The problem every time is that people deep dive into implementation details. And  I keep repeating that implementation is something the image builder should take care of, as the requirements per image are different.

 

But I seem to be talking to a brick wall...

[littlesat]

Even I ate quickly thinking of a solution = code.... you have to thank colleagues that hit the break and point you back to the design stage....!

[Persian Prince]

Hello everyone,

 

We store MACHINE name in "/etc/openvision/model" (Open Vision images) so we could use it in shell and other places which we can't use getBoxType, do you keep machine names somewhere in PLi?

 

I can provide a kernel module to create

 

/proc/stb/info/enigma2model

 

for example to store the MACHINE name from OE, if you're agree with this we could use it instead of

 

/proc/stb/info/hwmodel
/proc/stb/info/gbmodel
/proc/stb/info/boxtype
/proc/stb/info/vumodel
/proc/stb/info/azmodel

 

to check one proc file globally for all in all places, even reduce checks in enigma2 itself.

 

The reason behind this is https://github.com/O...e-core/pull/841 which made BackupSuite not compatible with PLi as we're using full machine names like "vuduo" instead of "duo" in the new "lookuptable.txt"

 

https://github.com/O...upsuite.sh#L214 returns "duo" for you so the new "lookuptable.txt" won't understand it.

 

Regards,

Persian Prince

Ok master branch is for PLi and feel free to send PRs or work on it directly (let me know if you want write access).

 

I just created a new branch "develop" which is for Open Vision only without "lookuptable.txt" and "findkerneldevice" files and less python checks.

 

We have extra files for detecting almost everything so the new branch won't work on PLi.

[WTE]

I was making something based on os-release from openembedded meta-core which I think is for every image easy to add and I think very usable to collect info from if needed.

I saw when I was making something that oe-alliance had already this but very image based.

As start I added some options from openpli and oe-alliance and to avoid adjustment (why should someone do this?) set it on read only.

Please check as maybe it's easy for maintainers like backupsuite or something. The total boxbranding is in my opinion strange as why make 5 images for same hardware when one works on all. Anyway this is easy to add in openpli and oe-alliance images.

It can been extent with lot more options like for example done by openatv https://github.com/o...version-info.bb

 

In attachment the bitbake file

 

 

 

Attached Files

•  os-enigma2.zip   1.12KB   6 downloads

[WanWizard]

The point of a "hardware info abstraction" layer is twofold:

1. to create a unified interface for all images, with a Python and C interface, to aid code portability between images
   
   This means Python code should be able to do
   

   import somefile
   value = somefile.somemethod()
   

   and not worry where this value comes from. It could be from custom boxbranding code, something generated at build time, a file in /etc, a mainframe in the corner of the kitchen, all not relevant. As I wrote before, implementation is something every image can do for themselfs, as it is hidden behind the common interface. This also allows some image makers to produce an image per model, while others produce one per MACHINE.
    

2. to simplify the code of both Enigma and plugins, as all current "I'll do my own detection" code can be removed.

 

To be able to archieve this, we need

1. Agreement amongst image makers that this is the way forward
    
2. A github repo with wiki to public the interface API and wiki documentation
    
3. A cross-image team of people who will maintain this API and its versioning, and to guard against backward incompatibility

In all, not really rocket science, if the will is there. In the time this thread is running, it could have been dealt with...