772 replies to this topic

[Persian Prince]

Please read, as that is EXACTLY what he is proposing.

nope.... two procs wherry suggested. One for brand and one for model....

cat /proc/stb/info/branding
model=h9combo
brand=Zgemma
....etc....

but again this is implementation....

At the end you need a function... and that we already have via /Components/About.py for a long long time...

That was just an example, one proc file to have everything is the best

Edited by Persian Prince, 16 July 2020 - 17:23.

[Erik Slagter]

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).

 

I am not sure if we can add items to an area that is claimed by code from the drivers. Also, this would require to create a kernel module, are you prepared to dive into that

 

Some filesystems (I am not sure about UBIFS) define extended attributes and one of them is an "immutable" flag, so this file could reside in the image.

 

I would like to stress that not having proper "box branding" is not only a result of too little attention. In basis there should be no need for such a thing. In an ideal world, vendors would hide all differences with other vendors and modules and the drivers would act as an abstraction layer. For relevant differences (only a few) the /proc nodes could be consulted. And then there would be no need for any code in enigma (either cpp or Python) to deal with differences between models. But we all know vendors are to lazy and/or incompetent to achieve that.

 

So I agree with Wanwizard to at least do it right on our side then.

[WTE]

Just an idea

 

This topic is eventually more about OEM models right?

I think you should check first if you can build one packages for more boxes.

 

Like you have trio4k, sf8008, ustym which are the "same manufacture" but on build/feed side it's mayor and time wasting as for all boxes an own MACHINE feed is made.

I think you should have an "OEM-Machine" feed which has linuxkernel, hbbtv, kodi, webkit, chromium. Then eventually in Machine feed you have just a couple of packages left which specify the box.

 

For boxes with one driver and don't do OEM machine names it's maybe possible to add in the end of the build an extra file/ feed which informs the brand.

I do not know of bitbake this all is possible but I prefer fewer packages builds first and see then how to brand it better.

[IanSav]

Hi,

 

I am not going to make specific quotes but I am concerned when people talk about using some of this information to make decision on how Enigma2 may operate.  In particular I strongly object to code that says something like if this is box model x, or model y then do something special.  This is maintenance insanity.  All these decisions based on hardware differences should *NEVER* be exposed to any part of Enigma2.

 

I believe this should be done by providing a list of features and then making Enigma2 decisions based on the feature (and NOT the box that may or may not offer it).  For example, I think it better to know if a box has a front panel power led, does it have a HDMI input, does it have a LCD/OLED front panel display, does it have a 7 segment LED display etc.  How this information is determined should be totally irrelevant to the bulk of Enigma2.

 

In Enigma2 I would like to only see code like if this box has a 7 segment LED then do something.  If this box has a HDMI input port than include this menu etc.  There should be no mention of the box brand, make model or anything else specific about the hardware *anywhere* in the bulk of Enigma2.  All we should be interested in is features.  This is something that boxbranding has tried to do.  Unfortunately coders still manage to abuse boxbranding to do the wrong things.

 

It is fine to talk about an API and other implementation details but I think we should be making an effort to define what we need to know and how we want to gather and parametrise the data so that an appropriate API can be designed.

 

In my earlier examples I indicated that I want to know the display ready image name (Beyonwiz, OpenATV, OpenPLi, OpenVision, OpenViX, etc).  I also want to know the hardware manufacturer name (Beyonwiz, GigaBlue, VU+, Zgemma, etc) and the model name (T3, T4, U4, V2, DUO 2, UE4K, etc).  I want this information to add to display information for users.  As I suggested above, and has been somewhat done by boxbranding, we need to create a list of all the hardware features that may have an impact on what Enigma2 needs to know or can affect its operation.

 

In my opinion, we should be getting the list of what we need to know organised.  We then need to think about how that information should be presented.  Should it be a string, an integer a Boolean?  Then is it immutable or can the state or feature be changed.  Once we have a reasonably complete list of features that we need to track then we can decide how and where the API can be created.  We should also keep in mind that the list of features may change.  Some feature may fall out of use and others may be added.  The design must allow this sort of flexibility.

 

We need to understand the data and the needs for that data *before* an API can be defined and the data identification (access) indexes or labels can be created.  Once designed this *must* be standardised across *all* images.

 

Okay, I have had my little rant.    What do people think?  Should we start collecting a list of features that we need to manage?  If that is agreeable can we agree to start with the features exposed and listed by boxbranding and then fill out the list with any information that is not currently offered by boxbranding?

 

Regards,

Ian.

[WTE]

Hi,

 

I am not going to make specific quotes but I am concerned when people talk about using some of this information to make decision on how Enigma2 may operate.  In particular I strongly object to code that says something like if this is box model x, or model y then do something special.  This is maintenance insanity.  All these decisions based on hardware differences should *NEVER* be exposed to any part of Enigma2.

 

I believe this should be done by providing a list of features and then making Enigma2 decisions based on the feature (and NOT the box that may or may not offer it).  For example, I think it better to know if a box has a front panel power led, does it have a HDMI input, does it have a LCD/OLED front panel display, does it have a 7 segment LED display etc.  How this information is determined should be totally irrelevant to the bulk of Enigma2.

 

In Enigma2 I would like to only see code like if this box has a 7 segment LED then do something.  If this box has a HDMI input port than include this menu etc.  There should be no mention of the box brand, make model or anything else specific about the hardware *anywhere* in the bulk of Enigma2.  All we should be interested in is features.  This is something that boxbranding has tried to do.  Unfortunately coders still manage to abuse boxbranding to do the wrong things.

 

It is fine to talk about an API and other implementation details but I think we should be making an effort to define what we need to know and how we want to gather and parametrise the data so that an appropriate API can be designed.

 

In my earlier examples I indicated that I want to know the display ready image name (Beyonwiz, OpenATV, OpenPLi, OpenVision, OpenViX, etc).  I also want to know the hardware manufacturer name (Beyonwiz, GigaBlue, VU+, Zgemma, etc) and the model name (T3, T4, U4, V2, DUO 2, UE4K, etc).  I want this information to add to display information for users.  As I suggested above, and has been somewhat done by boxbranding, we need to create a list of all the hardware features that may have an impact on what Enigma2 needs to know or can affect its operation.

 

In my opinion, we should be getting the list of what we need to know organised.  We then need to think about how that information should be presented.  Should it be a string, an integer a Boolean?  Then is it immutable or can the state or feature be changed.  Once we have a reasonably complete list of features that we need to track then we can decide how and where the API can be created.  We should also keep in mind that the list of features may change.  Some feature may fall out of use and others may be added.  The design must allow this sort of flexibility.

 

We need to understand the data and the needs for that data *before* an API can be defined and the data identification (access) indexes or labels can be created.  Once designed this *must* be standardised across *all* images.

 

Okay, I have had my little rant.    What do people think?  Should we start collecting a list of features that we need to manage?  If that is agreeable can we agree to start with the features exposed and listed by boxbranding and then fill out the list with any information that is not currently offered by boxbranding?

 

Regards,

Ian.

 

So if I understand you correct is that you want to create for everything a separate module, for HMDI, Scart, Ypbpr, Composite. A list ? will tell which components need to been installed and so this options will been provide in Enigma2.

I think as Enigma2 has only a couple of hardware options that https://github.com/O...s/SystemInfo.py is working fine or not?

 

So if I understand right you want a universal SystemInfo.py but outside Enigma2 code?

[Persian Prince]

Just an idea
 
This topic is eventually more about OEM models right?
I think you should check first if you can build one packages for more boxes.
 
Like you have trio4k, sf8008, ustym which are the "same manufacture" but on build/feed side it's mayor and time wasting as for all boxes an own MACHINE feed is made.
I think you should have an "OEM-Machine" feed which has linuxkernel, hbbtv, kodi, webkit, chromium. Then eventually in Machine feed you have just a couple of packages left which specify the box.
 
For boxes with one driver and don't do OEM machine names it's maybe possible to add in the end of the build an extra file/ feed which informs the brand.
I do not know of bitbake this all is possible but I prefer fewer packages builds first and see then how to brand it better.

This is great and I did similar in Open Vision for some brands/models but I think we can do more

[Persian Prince]

Hi,

I am not going to make specific quotes but I am concerned when people talk about using some of this information to make decision on how Enigma2 may operate. In particular I strongly object to code that says something like if this is box model x, or model y then do something special. This is maintenance insanity. All these decisions based on hardware differences should *NEVER* be exposed to any part of Enigma2.

I believe this should be done by providing a list of features and then making Enigma2 decisions based on the feature (and NOT the box that may or may not offer it). For example, I think it better to know if a box has a front panel power led, does it have a HDMI input, does it have a LCD/OLED front panel display, does it have a 7 segment LED display etc. How this information is determined should be totally irrelevant to the bulk of Enigma2.

In Enigma2 I would like to only see code like if this box has a 7 segment LED then do something. If this box has a HDMI input port than include this menu etc. There should be no mention of the box brand, make model or anything else specific about the hardware *anywhere* in the bulk of Enigma2. All we should be interested in is features. This is something that boxbranding has tried to do. Unfortunately coders still manage to abuse boxbranding to do the wrong things.

It is fine to talk about an API and other implementation details but I think we should be making an effort to define what we need to know and how we want to gather and parametrise the data so that an appropriate API can be designed.

In my earlier examples I indicated that I want to know the display ready image name (Beyonwiz, OpenATV, OpenPLi, OpenVision, OpenViX, etc). I also want to know the hardware manufacturer name (Beyonwiz, GigaBlue, VU+, Zgemma, etc) and the model name (T3, T4, U4, V2, DUO 2, UE4K, etc). I want this information to add to display information for users. As I suggested above, and has been somewhat done by boxbranding, we need to create a list of all the hardware features that may have an impact on what Enigma2 needs to know or can affect its operation.

In my opinion, we should be getting the list of what we need to know organised. We then need to think about how that information should be presented. Should it be a string, an integer a Boolean? Then is it immutable or can the state or feature be changed. Once we have a reasonably complete list of features that we need to track then we can decide how and where the API can be created. We should also keep in mind that the list of features may change. Some feature may fall out of use and others may be added. The design must allow this sort of flexibility.

We need to understand the data and the needs for that data *before* an API can be defined and the data identification (access) indexes or labels can be created. Once designed this *must* be standardised across *all* images.

Okay, I have had my little rant. What do people think? Should we start collecting a list of features that we need to manage? If that is agreeable can we agree to start with the features exposed and listed by boxbranding and then fill out the list with any information that is not currently offered by boxbranding?

Regards,
Ian.

I'm always glad we have you in enigma2 scene Ian

You have my word that we follow this kind of development in Open Vision, we have the branding module but more adapted to PLi code not OE-A: https://github.com/O...branding-module

We don't have the HDMI and hardware specific features but after your post I'm going to use it that way as make sense more.

Edited by Persian Prince, 17 July 2020 - 12:13.

[IanSav]

Hi WTE,

 

So if I understand you correct is that you want to create for everything a separate module, for HMDI, Scart, Ypbpr, Composite. A list ? will tell which components need to been installed and so this options will been provide in Enigma2.

I think as Enigma2 has only a couple of hardware options that https://github.com/O...s/SystemInfo.py is working fine or not?

 

So if I understand right you want a universal SystemInfo.py but outside Enigma2 code?

 

 

I am not yet advocating on where or how the data should be managed.  First I think we should work out what we need and want to know.

 

I think that SystemInfo.py is fine to deliver the data to the Python code but I know that some people do not want to use SystemInfo.py.  We should consider how to make the data available to shell scripts and the C++ layer code if required.  Some people have suggested a hardware profile text file.  This could be a good primary data source that can be read and used by shell scripts, C++ code and Python.

 

If I gave you the opinion that I want to have separate modules and sources for the data then that is not correct.  I think we should try to minimise the number of places where this information is managed and stored.  If is is difficult to manage then it is likely that people will want to fork or clone the data. This would be bad.

 

So far in boxbranding the following hardware and software information is available:

getBoxType
getBrandOEM
getDisplayType
getDriverDate
getFeedsUrl
getHaveAVJACK
getHaveCI
getHaveDVI
getHaveHDMI
getHaveHDMIinFHD
getHaveHDMIinHD
getHaveMiniTV
getHaveRCA
getHaveSCART
getHaveSCARTYUV
getHaveTranscoding1
getHaveTranscoding2
getHaveWOL
getHaveWWOL
getHaveYUV
getImageArch
getImageBuild
getImageDevBuild
getImageDistro
getImageFileSystem
getImageFolder
getImageType
getImageVersion
getMachineBrand
getMachineBuild
getMachineKernelFile
getMachineMKUBIFS
getMachineMake
getMachineMtdKernel
getMachineMtdRoot
getMachineName
getMachineProcModel
getMachineRootFile
getMachineUBINIZE
getOEVersion

To this list I would like to add the image name.  We could add if the box allows for multiple remote controls (remote control code selector).  What else do we need to know about the hardware and software that may have an impact on how Enigma2 needs to run?  I think this is the important first question / step.

 

What do others think?

 

Regards,

Ian.

[Taapat]

 

Just an idea
 
This topic is eventually more about OEM models right?
I think you should check first if you can build one packages for more boxes.
 
Like you have trio4k, sf8008, ustym which are the "same manufacture" but on build/feed side it's mayor and time wasting as for all boxes an own MACHINE feed is made.
I think you should have an "OEM-Machine" feed which has linuxkernel, hbbtv, kodi, webkit, chromium. Then eventually in Machine feed you have just a couple of packages left which specify the box.
 
For boxes with one driver and don't do OEM machine names it's maybe possible to add in the end of the build an extra file/ feed which informs the brand.
I do not know of bitbake this all is possible but I prefer fewer packages builds first and see then how to brand it better.

This is great and I did similar in Open Vision for some brands/models but I think we can do more

 

This is no problem if you build images one at a time at home.

However, this causes problems if you on a builserver in parallel build many images for different hardware.

In fact, all enigma python files and python plugins could be built with the architecture all as one package for all receivers.

On OpenPli it was created a long time ago.

However, these files have build dependencies on architecture-specific files, so on build they were deleted and rebuilded each time for each receiver.

Therefore, when you automatically copy these packages to the feed server after image building many receivers missing these packages because on the build server they were deleted by building in parallel the image for the next receiver.

Therefore, openpli abandoned such common packages.

Edited by Taapat, 17 July 2020 - 14:26.

[WanWizard]

So if I understand right you want a universal SystemInfo.py but outside Enigma2 code?

 
Sort of. Not only outside E2, but also the same API for all image builders. So a plugin developer can expect the API to be there, and have the method the developer needs.
 
I'm am against anything file based, simply because it is mutable by the enduser (and very easily so), and especially if it is in /etc, it might end up on a different box due to backup/restore or copy actions of that enduser, with all horror that comes from that.
 

I think that SystemInfo.py is fine to deliver the data to the Python code but I know that some people do not want to use SystemInfo.py.

 

The problem I have with SystemInfo, apart from the fact it is a global datastructure and not an immutable object with callable methods, it that is it limited to Python only. The E2 C code is also littered with reading proc nodes etc...

 

Like I said, I have no issue with OE-A's boxbranding API, it is already in use in a lot of code, and it is quite feature complete.

 

I do have an issue with it's implementation, which is why I want to decouple the two, and I have an issue with the fact OE-A can single-handedly decide to make breaking changes, as there is no multi-team oversight on the definition of the API.

 

In my opinion not that complicated, move the API definition to a separate repo (on neutral ground), give a nominated person from every team access to it, agree to only implement API changes after agreement, and introduce API versioning. This repo could then contain things like the C header file, and a wiki page with the API definition (method, arguments, argument type, input required, output type, etc). Like one would document every class...

[Huevos]

Hi WTE,

 

So if I understand you correct is that you want to create for everything a separate module, for HMDI, Scart, Ypbpr, Composite. A list ? will tell which components need to been installed and so this options will been provide in Enigma2.

I think as Enigma2 has only a couple of hardware options that https://github.com/O...s/SystemInfo.py is working fine or not?

 

So if I understand right you want a universal SystemInfo.py but outside Enigma2 code?

 

 

I am not yet advocating on where or how the data should be managed.  First I think we should work out what we need and want to know.

 

I think that SystemInfo.py is fine to deliver the data to the Python code

 

What do others think?

 

Regards,

Ian.

Ian, you know we already have that in SystemInfo in OpenViX, OpentATV, etc. e.g...

SystemInfo["FrontpanelDisplay"] = fileExists("/dev/dbox/oled0") or fileExists("/dev/dbox/lcd0")
SystemInfo["7segment"] = getDisplayType() in ("7segment",)
SystemInfo["ConfigDisplay"] = SystemInfo["FrontpanelDisplay"] and not SystemInfo["7segment"]
SystemInfo["LCDSKINSetup"] = pathExists("/usr/share/enigma2/display") and not SystemInfo["7segment"]
SystemInfo["DisplayLED"] = getBoxType() in ("gb800se", "gb800solo", "gbx1", "gbx2", "gbx3", "gbx3h")
SystemInfo["LEDButtons"] = getBoxType() == "vuultimo"
SystemInfo["HasHDMIin"] = getHaveHDMIinHD() in ("True",) or getHaveHDMIinFHD() in ("True",)
SystemInfo["HasInfoButton"] = getBrandOEM() in ("airdigital", "broadmedia", "ceryon", "dags", "dinobot", "edision", "formuler", "gfutures", "gigablue", "ini", "maxytec", "octagon", "odin", "skylake", "tiviar", "xcore", "xp", "xtrend")
SystemInfo["yellow_RCA_no_scart"] = not getHaveSCART() and (getHaveRCA() in ("True",) or getHaveAVJACK() in ("True",))
# Machines that do have SCART component video (red, green and blue RCA sockets).
SystemInfo["Scart-YPbPr"] = getBrandOEM() == "vuplus" and "4k" not in getBoxType()
# Machines that do not have component video (red, green and blue RCA sockets).
SystemInfo["no_YPbPr"] = not getHaveYUV()
# Machines that have composite video (yellow RCA socket) but do not have Scart.
SystemInfo["yellow_RCA_no_scart"] = not getHaveSCART() and (getHaveRCA() in ("True",) or getHaveAVJACK() in ("True",))
# Machines that have neither yellow RCA nor Scart sockets.
SystemInfo["no_yellow_RCA__no_scart"] = not getHaveRCA() and (not getHaveSCART() and not getHaveAVJACK())
SystemInfo["VideoModes"] = getChipSetString() in (  # 2160p and 1080p capable hardware...
	"5272s", "7251", "7251s", "7252", "7252s", "7278", "7366", "7376", "7444s", "72604", "3798mv200", "3798cv200", "hi3798mv200", "hi3798cv200"
) and (
	["720p", "1080p", "2160p", "1080i", "576p", "576i", "480p", "480i"],  # Normal modes.
	{"720p", "1080p", "2160p", "1080i"}  # Widescreen modes.
) or getChipSetString() in (  # 1080p capable hardware...
	"7241", "7356", "73565", "7358", "7362", "73625", "7424", "7425", "7552"
) and (
	["720p", "1080p", "1080i", "576p", "576i", "480p", "480i"],  # Normal modes.
	{"720p", "1080p", "1080i"}  # Widescreen modes.
) or (  # Default modes (neither 2160p nor 1080p capable hardware)...
	["720p", "1080i", "576p", "576i", "480p", "480i"],  # Normal modes.
	{"720p", "1080i"}  # Widescreen modes.
)
SystemInfo["LnbPowerAlwaysOn"] = getBoxType() in ("vusolo4k", "vuduo4k", "vuultimo4k", "vuuno4k", "vuuno4kse")

And SystemInfo keys were recently updated where possible to match corresponding keys in PLi SystemInfo.

 

Sometimes I get the feeling people are just commentating (and repeating what others are saying) without actually knowing what is already up and running in other distros.

 

Personally I see no reason why there can't be a subset of SystemInfo keys/values available in all distros... whether or not plugin writers would ever use them or any other "API" is a completely different issue.

[littlesat]

We should also get rit of that systeminfo.py!!!!! And replace it by something smarter..... so the idea to expand it is not a good idea... this part should be included in a new defined ‘branding’ thing... as you see above the addition do have complicated formules...

Edited by littlesat, 17 July 2020 - 20:30.

[WanWizard]

Exactly, what is the point of duplicating it? It looks more like a quick fix, but nobody bothered to make the rest of the changes.

 

Also, if you have complete control over your "boxbranding" design, why does this SystemInfo still have lots of "if ... then ... ?

[Huevos]

Exactly, what is the point of duplicating it? It looks more like a quick fix, but nobody bothered to make the rest of the changes.

 

Also, if you have complete control over your "boxbranding" design, why does this SystemInfo still have lots of "if ... then ... ?

Boxbranding is part of OE-A. SystemInfo is enigma. Nothing is being duplicated. Just setting some variables in SystemInfo that can be used anywhere in enigma python code.

[WanWizard]

Then you have missed the entire reason for this discussion.

 

The fact you state "Boxbranding is a part of OE-A" already means it is useless from a enigma team perspective, as appearently different teams using OE-A feel the need to augment it through SystemInfo.

 

What is the point of having it, as it clearly doesn't "brand the entire box" for you? What is the point for continuing to deal with hardware related data in multiple places?

 

This is what we are trying to find a common solution for.

[betacentauri]

IanSav in your list is PiP missing (with max PiP window size) and what kind of PiP is supported. Also max framebuffer resolution should be available.

[IanSav]

Hi Betacentauri,

 

I have workshopped that list a little bit.  Would you care to correct and expand on the list?

 

Regards,

Ian.

 

Attached Files

•  BoxInfo.txt   2.99KB   13 downloads

[littlesat]

Long time ago I was thinking about the build made a custom (during the build made) systeminfo.py with everything inside..... but that is also implementation... I even prefer to replace the complete systeminfo.py system by something else..... the boxbranding from oe-a is ‘just a kind of addition’ without solving the real problem from my point of view.... on my question why plugins need it I never get an answer....

Edited by littlesat, 18 July 2020 - 08:21.

[betacentauri]

I changed it a little bit.

- Added NumberOfPiPs, NumberOfTranscoders

 

First I think we should concentrate on the list and not on return type and names.

From my point of view we need to have for many of the SystemInfo variable a procedure in the list which can return the same or similar info.

 

So when I look e.g. here, I still see many things which are not in the list like DeepstandbySupport, HasHDMI-CEC, HasH265Encoder, HasHdrType, HasBypassEdidChecking,...

https://github.com/O...s/SystemInfo.py

https://github.com/o...s/SystemInfo.py

Attached Files

•  BoxInfo.txt   3.15KB   15 downloads

Edited by betacentauri, 18 July 2020 - 08:41.

[WTE]

Hi Betacentauri,

 

I have workshopped that list a little bit.  Would you care to correct and expand on the list?

 

Regards,

Ian.

 

So you want to supply static info and not read the /proc /dev /sys values?

That's in my opinion just asking for more problems, workarounds and so on.

 

Yes you have some hardware settings like the maximum resolution, maximum FPS, howmany encoders, howmany demuxers, HDCP support, Which GPU chipset, what kind of display, standby leds, cvbs by rca or jackplug, ypbpr, hdmi, hdmi max version and so on.

This should been possible to supply as static info in somekind of way.

 

How the image is setup, which filesystem if boot was from nand (mtd), TFcard or emmc (mmcblk*) is in my opinion to customized. How do you control USB boot, multiboot and so on with static info?

This info should not been provide in the same list right?