Jump to content


Photo

One proc file for detecting the MACHINE in all enigma2 images.


  • Please log in to reply
772 replies to this topic

Re: One proc file for detecting the MACHINE in all enigma2 images. #601 WanWizard

  • PLi® Core member
  • 70,235 posts

+1,798
Excellent

Posted 14 December 2020 - 22:43

No, I am saying that the order in which modules are loaded matters, if the module needs to use an existing proc path.

 

Say we go for /proc/stb/info, that means either /proc/stb already exists (box drivers are loaded first) or not, in which case it should be created. When it is created, the box driver may no longer load (as creating /proc/stb will fail).

 

This issue does not exist (and will not exist in the future) if we go for /proc/something-completely-unique-here/...


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: One proc file for detecting the MACHINE in all enigma2 images. #602 betacentauri

  • PLi® Core member
  • 7,185 posts

+323
Excellent

Posted 14 December 2020 - 23:57

Please don’t spend 1000 post regarding a name. Yes, it shouldn’t be a complete nonsense name, but eg
/proc/enigma2 or /proc/firmware or /proc/e2branding or something like this is ok. We can collect all possible names and can later vote for it.

The name is not enough. We still need to speak about the needed informations and what exactly the API should return. Only one example box name. Should it return hd51 or mutant51? If both are needed how do we call the proc files and so on.
There is still much to do.
Xtrend ET-9200, ET-8000, ET-10000, OpenPliPC on Ubuntu 12.04

Re: One proc file for detecting the MACHINE in all enigma2 images. #603 Persian Prince

  • Senior Member
  • 1,982 posts

+247
Excellent

Posted 15 December 2020 - 00:29

Please don’t spend 1000 post regarding a name. Yes, it shouldn’t be a complete nonsense name, but eg
/proc/enigma2 or /proc/firmware or /proc/e2branding or something like this is ok. We can collect all possible names and can later vote for it.

The name is not enough. We still need to speak about the needed informations and what exactly the API should return. Only one example box name. Should it return hd51 or mutant51? If both are needed how do we call the proc files and so on.
There is still much to do.

 

I think we talked about this before :)

 

Only a common path is needed not exact data.

 

We want to use hd51 as we use the machine name but another team may use mutant51 but we both use same proc so in all sources we know what brings that name.

 

But I'm not sure about something, do I need to add hardware features too?

 

Example:

 

/proc/openvision/lcd

 

then it writes "bwlcd128" or

 

/proc/openvision/transcoding

 

then it writes "True"


Open Vision sources: https://github.com/OpenVisionE2


Re: One proc file for detecting the MACHINE in all enigma2 images. #604 Persian Prince

  • Senior Member
  • 1,982 posts

+247
Excellent

Posted 15 December 2020 - 00:35

Also we can have subfolders like:

 

/proc/openvision/hardware/

 

then add hardware related proc entries

 

/proc/openvision/distro/

 

then add distro related proc entries

 

*openvision is the prototype name not the final solution.


Edited by Persian Prince, 15 December 2020 - 00:37.

Open Vision sources: https://github.com/OpenVisionE2


Re: One proc file for detecting the MACHINE in all enigma2 images. #605 WanWizard

  • PLi® Core member
  • 70,235 posts

+1,798
Excellent

Posted 15 December 2020 - 00:56

The name is not enough. We still need to speak about the needed informations and what exactly the API should return. Only one example box name. Should it return hd51 or mutant51? If both are needed how do we call the proc files and so on.

 

We want to use hd51 as we use the machine name but another team may use mutant51 but we both use same proc so in all sources we know what brings that name.

 

No.

 

What is returned is not relevant. I've been saying this since day one.

 

If someone thinks it is, it is because that person wants to apply logic to it ( i.e. if name = "hd51" then... ), and if that is the case, that person has missed the point of this exercise, which is to remove dependencies (and this if clearly creates a dependency).

 

So please explain why this is needed.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: One proc file for detecting the MACHINE in all enigma2 images. #606 betacentauri

  • PLi® Core member
  • 7,185 posts

+323
Excellent

Posted 15 December 2020 - 01:19

Maybe bad example from me. Better forget it.

Better example transcoding. Do we have one proc file named transcoding which returns True/False or true/false or 0/1. Or do we have more proc files as some boxes can transcode 2 streams. A transcoding proc and “numberOfTranscoder” proc. Or does transcoding proc returns 0, 1, 2 for the number of streams which can be transcoded? Do we need extra info for transcoding like the encoder device names and so on.
So many things to decide.
Xtrend ET-9200, ET-8000, ET-10000, OpenPliPC on Ubuntu 12.04

Re: One proc file for detecting the MACHINE in all enigma2 images. #607 Persian Prince

  • Senior Member
  • 1,982 posts

+247
Excellent

Posted 15 December 2020 - 01:23

Maybe bad example from me. Better forget it.

Better example transcoding. Do we have one proc file named transcoding which returns True/False or true/false or 0/1. Or do we have more proc files as some boxes can transcode 2 streams. A transcoding proc and “numberOfTranscoder” proc. Or does transcoding proc returns 0, 1, 2 for the number of streams which can be transcoded? Do we need extra info for transcoding like the encoder device names and so on.
So many things to decide.

 

I can add all those proc nodes but how you want to give them data in PLi?

 

I suggest start updating all metas with what you need.


Open Vision sources: https://github.com/OpenVisionE2


Re: One proc file for detecting the MACHINE in all enigma2 images. #608 WanWizard

  • PLi® Core member
  • 70,235 posts

+1,798
Excellent

Posted 15 December 2020 - 01:27

Maybe bad example from me. Better forget it.

Better example transcoding. Do we have one proc file named transcoding which returns True/False or true/false or 0/1. Or do we have more proc files as some boxes can transcode 2 streams. A transcoding proc and “numberOfTranscoder” proc. Or does transcoding proc returns 0, 1, 2 for the number of streams which can be transcoded? Do we need extra info for transcoding like the encoder device names and so on.
So many things to decide.

Better example. ;)


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: One proc file for detecting the MACHINE in all enigma2 images. #609 LraiZer

  • Senior Member
  • 101 posts

+19
Neutral

Posted 15 December 2020 - 01:50

Please don’t spend 1000 post regarding a name.

As i don't belong to any team, I can solve your name issue in a single post instead of a 1000 posts  :rolleyes:

 

Nomenclature has been decided, ALL TEAMS shall follow this decision and continue with other api spec discussion!
 
The OpenHAL API specs for version 1.0 of this hardware abstraction layer (HAL) shall be as follows:
 
common ground repo for openhal will be here: https://github.com/E...Plugins/OpenHAL
 
kernel module will be called: openhal.ko
 
proc path will be here: /proc/openhal/

 

Merry Xmas  ;)



Re: One proc file for detecting the MACHINE in all enigma2 images. #610 Persian Prince

  • Senior Member
  • 1,982 posts

+247
Excellent

Posted 15 December 2020 - 02:00

Please don’t spend 1000 post regarding a name.

As i don't belong to any team, I can solve your name issue in a single post instead of a 1000 posts  :rolleyes:
 
Nomenclature has been decided, ALL TEAMS shall follow this decision and continue with other api spec discussion!
 
The OpenHAL API specs for version 1.0 of this hardware abstraction layer (HAL) shall be as follows:
 
common ground repo for openhal will be here: https://github.com/E...Plugins/OpenHAL
 
kernel module will be called: openhal.ko
 
proc path will be here: /proc/openhal/
 
Merry Xmas  ;)

Naming isn't important now although you could check https://github.com/persianpros as I reserved some good and related org names like

https://github.com/OpenEnigma2

But openhal is like a team name and currently is openvision.

Open Vision sources: https://github.com/OpenVisionE2


Re: One proc file for detecting the MACHINE in all enigma2 images. #611 WanWizard

  • PLi® Core member
  • 70,235 posts

+1,798
Excellent

Posted 15 December 2020 - 02:23

As i don't belong to any team, I can solve your name issue in a single post instead of a 1000 posts  :rolleyes:

 

:lol: :lol: :lol:

 

I don't care at all what it is, but indeed, using "openSomething" might not be a good idea. Shorten it to "hal", problem solved. :P


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: One proc file for detecting the MACHINE in all enigma2 images. #612 Huevos

  • PLi® Contributor
  • 4,622 posts

+161
Excellent

Posted 15 December 2020 - 10:23

 

The name is not enough. We still need to speak about the needed informations and what exactly the API should return. Only one example box name. Should it return hd51 or mutant51? If both are needed how do we call the proc files and so on.

 

We want to use hd51 as we use the machine name but another team may use mutant51 but we both use same proc so in all sources we know what brings that name.

 

No.

 

What is returned is not relevant. I've been saying this since day one.

 

If someone thinks it is, it is because that person wants to apply logic to it ( i.e. if name = "hd51" then... ), and if that is the case, that person has missed the point of this exercise, which is to remove dependencies (and this if clearly creates a dependency).

 

So please explain why this is needed.

 

The whole project is pointless if the returned data is not identical in all distros. By the sound of it you seem to think this data is to be used for decorating the image, not for logic.


Edited by Huevos, 15 December 2020 - 10:24.


Re: One proc file for detecting the MACHINE in all enigma2 images. #613 littlesat

  • PLi® Core member
  • 57,064 posts

+698
Excellent

Posted 15 December 2020 - 10:52

if 'hd51' then do 'something else' is exactly what should be avoided... and why this discussion is needed. At the end it should be if 'feature available on this box' then 'use this feature' instead.... 

We strived to have the SystemInfo.py the only place where we have checks on box model but we already 'claim' a feature to it from there.... What is tried to design here is even remove the box model check out of here and go for the feature system somehow right away. And then we try to do this cross image...


WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: One proc file for detecting the MACHINE in all enigma2 images. #614 Huevos

  • PLi® Contributor
  • 4,622 posts

+161
Excellent

Posted 15 December 2020 - 11:12

if 'hd51' then do 'something else' is exactly what should be avoided... and why this discussion is needed. At the end it should be if 'feature available on this box' then 'use this feature' instead.... 

We strived to have the SystemInfo.py the only place where we have checks on box model but we already 'claim' a feature to it from there.... What is tried to design here is even remove the box model check out of here and go for the feature system somehow right away. And then we try to do this cross image...

That is not how procs are currently used throughout the image. Yes, some current procs are used in a boolean way but plenty more output strings that the logic uses.



Re: One proc file for detecting the MACHINE in all enigma2 images. #615 littlesat

  • PLi® Core member
  • 57,064 posts

+698
Excellent

Posted 15 December 2020 - 12:48

What is done in SystemInfo.py is our implementation. We strived this was our only file in e2 that contains box model checks. Instead of check for box model it better could parse some procs to check for specific features.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: One proc file for detecting the MACHINE in all enigma2 images. #616 Huevos

  • PLi® Contributor
  • 4,622 posts

+161
Excellent

Posted 15 December 2020 - 14:23

 

The name is not enough. We still need to speak about the needed informations and what exactly the API should return. Only one example box name. Should it return hd51 or mutant51? If both are needed how do we call the proc files and so on.

 

We want to use hd51 as we use the machine name but another team may use mutant51 but we both use same proc so in all sources we know what brings that name.

 

No.

 

What is returned is not relevant. I've been saying this since day one.

 

If someone thinks it is, it is because that person wants to apply logic to it ( i.e. if name = "hd51" then... ), and if that is the case, that person has missed the point of this exercise, which is to remove dependencies (and this if clearly creates a dependency).

 

So please explain why this is needed.

 

e.g. /proc/.../display would output one of the following...

'', 'textlcd', '7segment', 'bwlcd96', 'bwlcd128', 'bwlcd140', 'bwlcd255', 'colorlcd', 'colorlcd128',
'colorlcd220', 'colorlcd390', 'colorlcd400', 'colorlcd480', 'colorlcd720', 'colorlcd800'

Where would we be if every team just outputted any data it liked? Without 100% consistency the project is dead.



Re: One proc file for detecting the MACHINE in all enigma2 images. #617 LraiZer

  • Senior Member
  • 101 posts

+19
Neutral

Posted 15 December 2020 - 14:25

As i understand this, any feature that is an actual hardware capable api spec for which logic is allowed to be applied should be in path /proc/hal/*
 
Any results returned in the api spec that are allowed to be variable between images can only to be used for info/display purposes. No logic is allowed be be applied (eg. api spec for model simply asks to return a 16 byte max string). These should be in a sub info path /proc/hal/info/* 
 
returns api spec variable: (no logic allowed, info/display purposed only!)
 
/proc/hal/info/name
/proc/hal/info/model
/proc/hal/info/brand
/proc/hal/info/distro
 
returns api spec as defined: (logic allowed!)
 
/proc/hal/kernel
/proc/hal/python
/proc/hal/architecture
/proc/hal/socfamily


Re: One proc file for detecting the MACHINE in all enigma2 images. #618 WanWizard

  • PLi® Core member
  • 70,235 posts

+1,798
Excellent

Posted 15 December 2020 - 14:48

The whole project is pointless if the returned data is not identical in all distros. By the sound of it you seem to think this data is to be used for decorating the image, not for logic.

 

It seems to me that you have totally missed the point of this entire exercise.

 

If there is any need to use if name == "hd51" then, then the API is missing information. Please give an example where you feel you need this, and I'll prove you wrong.
 


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: One proc file for detecting the MACHINE in all enigma2 images. #619 WanWizard

  • PLi® Core member
  • 70,235 posts

+1,798
Excellent

Posted 15 December 2020 - 14:51

Where would we be if every team just outputted any data it liked? Without 100% consistency the project is dead.

 

You also seem to miss the difference between "random" string data, and a specific value or value list.

 

Obviously, a list of values should follow the spec, like boolean and numeric values should.

 

But name is just a display string, and therefor its value is of no importance. The spec should just define it as "a string". There is no reason to apply logic to a field like "name".


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: One proc file for detecting the MACHINE in all enigma2 images. #620 littlesat

  • PLi® Core member
  • 57,064 posts

+698
Excellent

Posted 15 December 2020 - 14:58

Why do we need Hal?

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W



20 user(s) are reading this topic

0 members, 20 guests, 0 anonymous users