772 replies to this topic

[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

[WanWizard]

We (as all teams together) are running into this issue more and more often. The problem only grows exponentionally with every new image launched.

 

Everyone tries to find their own solution, not only on an image level, but even on a plugin level (look at the elaborate code in OWIF).

 

It is about time we stick our heads together and come up with a generic solution that works across images, that defines an API but leaves the implementation free for everyone, with an API that is available to both Enigma and plugins directly.

 

Special attention needs to be given to API versioning, as it is absolutely critical that no backward incompatible changes are introduced.

[Persian Prince]

If we have a new external module and load it we can even detect when the image is in multiboot situation but the bad thing is we may lose the proc file in multiboot.

Another easy solution is what I did in Open Vision, simply save MACHINE from OE to a location like "/etc/openvision/model" but if everyone agree we could use a universal path like

/etc/enigma2/model

and

/etc/enigma2/brand

for detecting the brand/meta, we could reduce some checks with brand instead of "this model" or "that model".

[WanWizard]

That would only work if everyone uses exactly the same model.

 

OE-A for example creates images per vendor model (so it has 4 different images for the Zgemma H9 for example), while we only make one H9 image for all compatible boxes.

 

And it would still require every image and every plugin (if needed) to have their own redundant code to deal with all other aspects.

 

Ideally you have a solution that deals with all hardware dependent thinks, from everything in SystemInfo to serving the remote, box picture and remote keymaps for E2 and OWIF...

[Persian Prince]

OE-A could use

 

/etc/enigma2/model

/etc/enigma2/brand

 

and

 

/etc/enigma2/type

 

for hardware/vendor type

[WanWizard]

Not really a fan of creating lots of files. Especially not if they are mutable, if that would be the way to go, it would be better to create something like /proc/stb/enigma...

[IanSav]

Hi,

 

I am *very* interested in this topic.  This issue has been a significant cause of frustration for me in refactoring Enigma2 code.

 

This issue appears to be mostly resolved on OE-Alliance images by using the boxbranding module.  I know this is not welcomed on OpenPLi but it could be one solution to this issue.  Huevos offered a Python implementation to OpenPLi but that doesn't appear to have gone anywhere.

 

Rather than importing yet another module into may Enigma2 modules I would like to suggest that we use the existing SystemInfo dictionary mechanism.  This would allow all Enigma2 code and plugins access an already globally available module to get this extra information.

 

In my new Setup refactor I now have the following code:
 

from Components.SystemInfo import SystemInfo

...

itemText = itemText.replace("%s %s", "%s %s" % (SystemInfo["MachineBrand"], SystemInfo["MachineName"]))
itemDescription = itemDescription.replace("%s %s", "%s %s" % (SystemInfo["MachineBrand"], SystemInfo["MachineName"]))

In SystemInfo.py on OpenViX I have:

from boxbranding import getBoxType, getBrandOEM, getDisplayType, getHaveAVJACK, getHaveHDMIinFHD, getHaveHDMIinHD, getHaveRCA, getHaveSCART, getHaveYUV, getMachineBrand, getMachineBuild, getMachineMtdRoot, getMachineName

...

SystemInfo["MachineBrand"] = getMachineBrand()
SystemInfo["MachineName"] = getMachineName()

In SystemInfo.py on OpenPLi I have:

from Tools.HardwareInfo import HardwareInfo

...

model = HardwareInfo().get_device_model()
SystemInfo["MachineBrand"] = HardwareInfo().get_machine_name()
SystemInfo["MachineName"] = model

My point is that within Setup.py I use one defined API to get system information and on each image that information is provided by whatever mechanism is deemed appropriate.

 

What is critically important is to define a list of all these SystemInfo dictionary entry keys that will hold all the information desired.  I would like to suggest that we use the list from the OE-Alliance boxbranding as a starting point and then define and publish the keys that will be used and what those keys will hold.

 

Regards,

Ian.

[IanSav]

Hi,

 

I forgot to ask, on OpenPLi what is the correct way to get the manufacturer name and the model number of the current device?  Also what is the official way to get the display ready version of the current image?

 

In my case I am using hardware like "Zgemma H7C" and "Beyonwiz T3" on both OpenViX and OpenPLi.  I would like to get the following data:

SystemInfo["MachineBrand"] = "Zgemma" or "Beyonwiz" as appropriate.

SystemInfo["MachineName"] = "H7C" or "T3" as appropriate.

SystemInfo["ImageName"] = "OpenPLi" or "OpenViX" as appropriate.

 

Note that I want to get the data with the correct capitalisation and presentation ready to display to a user.  The data can be forced into all upper or all lowercase programmatically if required.

 

Regards,

Ian.

[WanWizard]

You can't implement it in Python as you also need the information in the C layer, and possible also in bash scripts...

 

Another big annoyance of the current solution is that SystemInfo is a global (which is itself is already a big no), and it's mutable.

I don't have an issue with "a" boxbranding as such, on the contrary, this topic is a clear indication it is needed. I do have an issue with the current OE implementation, as we have a completely different way of building images.

 

Which is why I suggest to try to agree to a API, and leave the implementation to every individual team...

[WanWizard]

I forgot to ask, on OpenPLi what is the correct way to get the manufacturer name and the model number of the current device?

 

We currently don't have that, as we build per MACHINE, not per box model. Which is one of the many differences the API needs to cover...

[IanSav]

Hi WanWizard,

 

I agree that much of SystemInfo is abused but I feel that this is a valid application for its use.

 

Mutability is an issue but I must admit to using SystemInfo as a variable store where mutability is a requirement.  Perhaps a refinement of SystemInfo with appropriate method APIs is a/the solution.

 

Regards,

Ian.

Edited by IanSav, 12 July 2020 - 14:18.

[WanWizard]

It contains hardware information, which per definition is not (or should not be) mutable. Ideally it should therefore be an object with getters only.

 

And as said, an implementation in Python doesn't provide a solution for everything outside of Python. It is not generic enough.

 

I still prefer the proc solution, as it will also provide solutions for things like images (box, remotes) and XML files (p.e. remote key mappings).

[IanSav]

Hi WanWizard,

 

Then the data could be stored in a simple text file that is created by the build process and can be accessed via shell scripts, C++ code and Python.  Perhaps something like this:

# This is the BoxBranding definition for a Zgemma H7.
#
getBoxType=zgemmah7
getBrandOEM=airdigital
getDisplayType=7segment
getDriverDate=20191123
getFeedsUrl=http://openvixdev.satellites-xml.org/feeds/openvix/developer/5.3/h7
getHaveAVJACK=True
getHaveCI=True
getHaveDVI=False
getHaveHDMI=True
getHaveHDMIinFHD=False
getHaveHDMIinHD=False
getHaveMiniTV=False
getHaveRCA=False
getHaveSCART=False
getHaveSCARTYUV=False
getHaveTranscoding1=
getHaveTranscoding2=True
getHaveWOL=False
getHaveWWOL=False
getHaveYUV=False
getImageArch=cortexa15hf-neon-vfpv4
getImageBuild=015
getImageDevBuild=004
getImageDistro=OpenViX
getImageFileSystem=airdigitalemmc
getImageFolder=zgemma/h7
getImageType=developer
getImageVersion=5.3
getMachineBrand=Zgemma
getMachineBuild=h7
getMachineKernelFile=kernel.bin
getMachineMKUBIFS=
getMachineMake=zgemmah7
getMachineMtdKernel=mmcblk0p2
getMachineMtdRoot=mmcblk0p3
getMachineName=H7
getMachineProcModel=h7
getMachineRootFile=rootfs.tar.bz2
getMachineUBINIZE=
getOEVersion=OE-Alliance 4.3

This was derived from boxbranding on OpenViX but it makes a good example of what I meant.  I still think that all the labels (to the left of the = sign) need to be well defined and agreed upon by all images.

 

Regards,

Ian.

Edited by IanSav, 12 July 2020 - 14:34.

[Persian Prince]

Still I vote for a file so we could use it everywhere

 

proc file is good but in my opinion a normal file is better.

[WanWizard]

The difference is that a proc is readonly, a file is read-write (or even delete). Especially a problem when you're talking backup / restores, one of the reasons I don't want files in /etc.

[Huevos]

This is never going to work cross distro because PLi only build a subset of images. i.e. getBoxType does not contain the model name of the hardware. So getBoxType from enigma does not return the same data as getBoxType from the branding module.

 

Until such a time that PLi use the full set of machine names and build images for them all, I can't see how we can go forwards with this... PLi don't even have environmental variables available in the build environment like OE-Alliance.

Edited by Huevos, 13 July 2020 - 01:09.

[Huevos]

e.g...

in OE-Alliance we have:
- zgemmah92h
- zgemmah92s
- zgemmah9combo
- zgemmah9s
- zgemmah9t
- zgemmah9twin

whereas OpenPLi only has:
- zgemmah9


 

[Persian Prince]

This is never going to work cross distro because PLi only build a subset of images. i.e. getBoxType does not contain the model name of the hardware. So getBoxType from enigma does not return the same data as getBoxType from the branding module.

 

Until such a time that PLi use the full set of machine names and build images for them all, I can't see how we can go forwards with this... PLi don't even have environmental variables available in the build environment like OE-Alliance.

Even we have different results, we could use same proc files to reduce the checks

[littlesat]

When we have one image for multiple h9 boxes (which I prefer, why build multiple images when it can be one?! - you can still install the incorrect image and then the code says the different machine) the only way to determine the exact box type is verifying something on the box.... then a branding module with static values added to the image during compiling does not really help..... unless you add a peace of code....
Branding can be done in python and can be made accessible in cpp as well.

A good defined multi-image api might help.

Instead of static stuff it can also include a some code checking procs etc to find sub models....

Edited by littlesat, 13 July 2020 - 09:34.

[WanWizard]

This is never going to work cross distro because PLi only build a subset of images.

 

You missed the point.

 

I am talking about the API, not about the implemenation, and not the data. The only relevant point is that a getType() method exists, that its return value is defined, and the image adheres to the spec.

 

What it returns is not relevant, as none of the Enigma of Plugin code should apply any logic to the result of a getType() call. If it does, it is checking for some hardware dependency, which should be provided by the API.