772 replies to this topic

[WTE]

About boxinfo.txt

 

DisplayType        String        None, "7Segment", "LED" (Use HasXYZ options instead!)
Has7Segment        Boolean        Does device have 4 digit 7 segment front panel?

 

I assume Has7segment is already answer in DisplayType right ?

[betacentauri]

 

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?

 

The new boxbranding should read /proc /dev /sys values (if needed) and provide the info in a standardised format. E.g. there are several proc files regarding led in the power button /proc/stb/power/powerled, /proc/stb/fp/ledpowercolor, /proc/stb/fp/power4x7on and so on. The branding should just say it is supported or not. Well as I think about it, shouldn't the lib/branding be able to turn on/off the features. I think this would be a good idea as e.g. sometimes you have to write on/off and in other cases 0/1 into the /proc files. E2 don't know and shouldn't know which values it has to write. e2 should only activate/deactive the feature.

Edited by betacentauri, 18 July 2020 - 09:10.

[betacentauri]

And yes WTE is right that used mtd/mmcblk devices are not static on all devices. If a box support multiboot, the information may not be static. The lib/branding needs to deliver the correct values on the fly.

[Huevos]

Long time ago I was [...]. on my question why plugins need it I never get an answer....

I have answered this every time it gets asked. There is not one simple answer because the data from branding is so wide ranging. So here is an example...

 

____________________________________________

In a plugin...

 

Distro one want the plugin to show in plugin menu.

Distro two want the plugin to show in the main menu.

Distro three want the plugin in "Tuners and scanning" item 4.

Distro four want the plugin in "Tuners and scanning" item 8.

 

To do the above we need to know the distro.

_____________________________________________

 

 

 

 

 

[Huevos]

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?r.

You clearly don't get it. Branding is the building blocks. It is like flags. What is in those SystemInfo variables is combinations of box branding variables. e.g...

SystemInfo["yellow_RCA_no_scart"] = not getHaveSCART() and (getHaveRCA() in ("True",) or getHaveAVJACK() in ("True",))

 

[Erik Slagter]

 

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?

 

Please note that the information in the /proc nodes is not always correct. So there needs to be a layer between that and the client to optionally correct the info.

[littlesat]

You should indeed read procs.... only the functions/system need to be defined.
@Huevos, please forget the branding module from oe-a at this moment. Please just think about the problem that we tried to solve.
At this moment the box name/brand is done in About.py.... this should also be moved to the new system... this is also using procs... maybe for these we need a new common one... as this is now made by what the manufacturer dictates and a lot of boxes also have a dummy dmm8000 proc

Edited by littlesat, 18 July 2020 - 09:51.

[IanSav]

Hi WTE,

 

About boxinfo.txt

 

DisplayType        String        None, "7Segment", "LED" (Use HasXYZ options instead!)
Has7Segment        Boolean        Does device have 4 digit 7 segment front panel?

 

I assume Has7segment is already answer in DisplayType right ?

 

I started this list with items from "boxbranding".  I want to move on from there.  In this case I realised that naming the type of front panel using "DisplayType" is redundant information.  It also doesn't allow for boxes, like the VU+ DUO 2 that has multiple front panel displays.  I feel it is more appropriate to ask a list of questions like:
 

if BoxInfo.get("HasLED", False):
    do something with LED
elif BoxInfo.get(Has7Segment, False):
    do something with 7 segment display
elif BoxInfo.get("HasVFD", False):
    do something with VFD
...

So in this case I think "DisplayType" should not be used at all.

 

Regards,

Ian.

[littlesat]

That looks like the SystemInfo global. Why call it boxinfo ... when the key is mandatory you do not need a get function....

Edited by littlesat, 18 July 2020 - 10:15.

[IanSav]

Hi Littlesat,

 

That looks like the SystemInfo global. Why call it boxinfo ... when the key is mandatory you do not need a get function....

 

It does, doesn't it.    At least people can't complain that this is SystemInfo.

 

There is nothing wrong writing the get function defensively.  The flip side of the .get() method is the .set() method.  Here we can create mutable and immutable entries.    Still, this is just a discussion point sample in Python.  Don't format that we need to cater for shell and C++ code as well.

 

Regards,

Ian.

Edited by IanSav, 18 July 2020 - 10:28.

[littlesat]

Brainstorm.....
You can swig python into cpp look like it’s done for eg the config system..... config.systeminfo.... config.boxinfo can also do the ‘job’.... Why not? Then in settings you might ‘overrule’ the defaults when you like. The defaults are the values as it should be....

Edited by littlesat, 18 July 2020 - 10:53.

[WanWizard]

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

 

That is the direction I am thinking off, but then not in Python, but on a higher level (as it needs to be accessable from Bash, C and Python). Since it is hardware information, virtually everything in there is static data.

 

[WanWizard]

The new boxbranding should read /proc /dev /sys values (if needed) and provide the info in a standardised format. E.g. there are several proc files regarding led in the power button /proc/stb/power/powerled, /proc/stb/fp/ledpowercolor, /proc/stb/fp/power4x7on and so on. The branding should just say it is supported or not. Well as I think about it, shouldn't the lib/branding be able to turn on/off the features. I think this would be a good idea as e.g. sometimes you have to write on/off and in other cases 0/1 into the /proc files. E2 don't know and shouldn't know which values it has to write. e2 should only activate/deactive the feature.

 

A hardware abstraction layer, I like that even better...
 

[littlesat]

Yep another point the procs... sometimes 0, 1, sometimes on, off sometimes enable, disable.... crazy!!!!!! Even on one box it could be different.... this is something we a community should never accept.... and then two different procs for the same depending on the machine

[Huevos]

 

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

 

That is the direction I am thinking off, but then not in Python, but on a higher level (as it needs to be accessable from Bash, C and Python). Since it is hardware information, virtually everything in there is static data.

 

 

No, not all is hardware. Some of the variables are related to firmware, e.g. getImageArch(), which in the case of some boxes has changed, so not static either, just static for current build.

SUPPORTED_FUNCTIONS = [
# software specific
	'getDriverDate',
	'getImageArch',
	'getMachineKernelFile',
	'getMachineMKUBIFS',
	'getMachineMtdKernel',
	'getMachineMtdRoot',
	'getMachineRootFile',
	'getMachineUBINIZE',
	'getImageFileSystem',
# Distro/Build
	'getFeedsUrl',
	'getImageDistro',
	'getOEVersion',
	'getImageVersion',
	'getImageBuild',
	'getImageDevBuild',
	'getImageType',
	'getImageFolder',
	'getMachineBuild',
# These should be the same in all distros, but with non-OE-Alliance distros all bets are off.
	'getMachineName',
	'getMachineProcModel',
	'getBoxType',
# Manufacturer
	'getMachineMake',
	'getMachineBrand',
# Hardware specific functions
	'getBrandOEM',
	'getDisplayType',
	'getHaveAVJACK',
	'getHaveCI',
	'getHaveDVI',
	'getHaveHDMI',
	'getHaveHDMIinFHD',
	'getHaveHDMIinHD',
	'getHaveMiniTV',
	'getHaveRCA',
	'getHaveSCART',
	'getHaveSCARTYUV',
	'getHaveTranscoding1',
	'getHaveWOL',
	'getHaveWWOL',
	'getHaveYUV',
	'getHaveTranscoding2',]

Yep another point the procs... sometimes 0, 1, sometimes on, off sometimes enable, disable.... crazy!!!!!! Even on one box it could be different.... this is something we a community should never accept.... and then two different procs for the same depending on the machine

Yes, same problem with the name of the blindscan binary. Different name on every piece of hardware... and even worse on Vu+, has different names on different tuners. So you have to read the name of the tuner and select the correct binary based on tuner name.
 

Edited by Huevos, 19 July 2020 - 16:54.

[Huevos]

Long time ago I was thinking about the build made a custom (during the build made) systeminfo.py with everything inside....

How are you going to do that? PLi doesn't have any of this data available in the current build env. So are you going to add all that data to the build env? Because that would be good. I already have all the data.

 

https://github.com/H...plugin/machines

 

But we still have the problem of all the box names being different in PLi compared to all other distros.

Edited by Huevos, 19 July 2020 - 17:20.

[littlesat]

Maybe oe-a should adapt their homebrew bsp layers... ours are with the box names defined by the manufacturer... and the during build made systeminfo.py can be done... don not worry about that.

Edited by littlesat, 19 July 2020 - 19:15.

[WanWizard]

No, not all is hardware. Some of the variables are related to firmware, e.g. getImageArch(), which in the case of some boxes has changed, so not static either, just static for current build.

 

Sorry I wasn't clear enough.

 

I meant static as in "not changing at runtime", I didn't mean "hardcoded", some information needs to be detected at boot-up, especially for OpenPLi, as we don't have seperate builds for every model box.

[WanWizard]

How are you going to do that? PLi doesn't have any of this data available in the current build env. So are you going to add all that data to the build env? Because that would be good. I already have all the data.

 

That would be a logical next step, yes.

 

But we still have the problem of all the box names being different in PLi compared to all other distros.

 

Why is that relevant?

 

That suggests that you intent to apply logic to the information returned, which you shouldn't. Any logic related to "box branding" should be inside the branding layer, and abstracted from E2 or plugins...

[Huevos]

 

How are you going to do that? PLi doesn't have any of this data available in the current build env. So are you going to add all that data to the build env? Because that would be good. I already have all the data.

 

That would be a logical next step, yes.

 

But we still have the problem of all the box names being different in PLi compared to all other distros.

 

Why is that relevant?

 

That suggests that you intent to apply logic to the information returned, which you shouldn't. Any logic related to "box branding" should be inside the branding layer, and abstracted from E2 or plugins...

 

"Why is that relevant?"

 

If different distros return different machine names for the same box the project is pointless, because you can't do this:

if getBoxName() == "sf8008":

In OE-Alliance that will always return False.