772 replies to this topic

[littlesat]

I simply suggest we should not add info that already can be derived from other procs....: only add info that is not available yet... or that is currently derived with an if specific boxtype then... construction...

Edited by littlesat, 16 December 2020 - 15:18.

[WanWizard]

You need the path as well or just the picture name?

 

Give me an example of what you need.

 

If you don't have the full path, how can you load it?

Having it can replace the logic currently in Enigma and OWIF to try and find it, and logic in BB recipies to make sure picture names match what both expect to find.

[betacentauri]

 

Afaik not all boxes support PiP. And some can show up to 4 PiP “windows”. You can get the data on the fly like you can see it here: https://github.com/O...stemInfo.py#L17

MACHINE_FEATURE not that I know.

I think what SystemInfo.py is doing for that is easier so lets keep the module less complicated.

 

You need this variable as flash size: https://github.com/o...timo4k.conf#L12 ?

 

I changed my mind. Forget flash size. At runtime on the box I don't think that it is useful.

[Persian Prince]

 

You need the path as well or just the picture name?

 

Give me an example of what you need.

 

If you don't have the full path, how can you load it?

Having it can replace the logic currently in Enigma and OWIF to try and find it, and logic in BB recipies to make sure picture names match what both expect to find.

 

Full path for what?

 

All RC and box pictures are in one folder so why we need a path?

[WanWizard]

1. So you can decouple the location from the code
2. So you can share the same image between diffferent code (for example, both E2 and OWIF use a remote image, which is now on the box twice, possibly two different ones).

[Huevos]

Some lines there have ":".... shouln't we make it '=' at all places?

 

Some boxes have PIP yes/no depended on the boot mode... (mode 12 has it mode 1 not)... ? PIP is now arrange correctly via SystemInfo.py.

That is because whoever did those tests used "modinfo" when should have used "modinfo -d".

[Huevos]

 

1. So you can decouple the location from the code
2. So you can share the same image between diffferent code (for example, both E2 and OWIF use a remote image, which is now on the box twice, possibly two different ones).

 

What do you mean the image is on the box twice? I don't know about PLi but OE-A images use the image in /usr/share/enigma2/rc_models for OpenWebIF, Help, and Wizards.

Edited by Huevos, 16 December 2020 - 23:57.

[WanWizard]

Please explain what all these do then? https://github.com/E...n/public/images

[Huevos]

Please explain what all these do then? https://github.com/E...n/public/images

It is the same image for sure...

 

 1.jpg   192.61KB   2 downloads

 

 2.jpg   130.87KB   1 downloads

 

[Huevos]

Please explain what all these do then? https://github.com/E...n/public/images

The answer to your question is that those images are used in distros that don't support "from Components.RcModel import rc_model".

 

https://github.com/E...ers/base.py#L67

Edited by Huevos, 17 December 2020 - 00:46.

[WanWizard]

So something OE-A specific in a generic plugin?

 

If we do this right, that is something else that can go, as rc_model etc is definitely hardware info...

[Huevos]

So something OE-A specific in a generic plugin?

 

If we do this right, that is something else that can go, as rc_model etc is definitely hardware info...

OpenWebIF falls back to internal workarounds for distros not running branding. e.g. remote.png and OWIbranding.

[WanWizard]

Yes, but branding is going to disappear, that is the idea of this entire excersize.

[Persian Prince]

 

1. So you can decouple the location from the code
2. So you can share the same image between diffferent code (for example, both E2 and OWIF use a remote image, which is now on the box twice, possibly two different ones).

 

 

Current module returnes needed RC information you just need to put rc images at the same place if you want but some KBs won't save you anything.

[Persian Prince]

 

Some lines there have ":".... shouln't we make it '=' at all places?

 

Some boxes have PIP yes/no depended on the boot mode... (mode 12 has it mode 1 not)... ? PIP is now arrange correctly via SystemInfo.py.

That is because whoever did those tests used "modinfo" when should have used "modinfo -d".

 

":" info is not needed.

[Persian Prince]

 

 

1. So you can decouple the location from the code
2. So you can share the same image between diffferent code (for example, both E2 and OWIF use a remote image, which is now on the box twice, possibly two different ones).

 

What do you mean the image is on the box twice? I don't know about PLi but OE-A images use the image in /usr/share/enigma2/rc_models for OpenWebIF, Help, and Wizards.

 

 

OE-A may have saved some KBs but the code is: https://github.com/o...ding/RcModel.py

 

Not good at all.

[Persian Prince]

So something OE-A specific in a generic plugin?

 

If we do this right, that is something else that can go, as rc_model etc is definitely hardware info...

 

We removed that months ago, no offence but that code is rubbish.

 

You're right, module will replace that too.

[WanWizard]

[Persian Prince]

I'm waiting for a place to upload the first version, add the bitbake recipe as a PR to OE-A and PLi then we can move on and customize the module.

 

Module can be builded against all kernels so it's safe but we will change the enigma2 API later after we inregrated the module in all images and see the proc files.

 

First stage is to have the module installed in all images by default then correct the proc data and ...

 

Is https://github.com/OpenHAL ok? If it's ok please tell me who should I invite as organization members?

 

We need 1 person from each team, and if a team has more members with kernel experience we can invite more.

 

For example "betacentauri" must be on this project as he's a pro with kernels

Edited by Persian Prince, 17 December 2020 - 18:10.

[WanWizard]

I still think "OpenHAL" is not a good name (because of the "Open" and the similarity with image names). And I don't have a problem with using E2OpenPlugins as organisation, instead of creating a new one.

 

Also, why do members have to be kernel specialists? Once this stage is passed, there is nothing technical about maintaning the specs?