74 replies to this topic

[WanWizard]

Het probleem van de skin half op het scherm is een algemeen probleem, ik heb het ook al een paar keer gehad, bijvoorbeeld op de 10K.

[Erik Slagter]

Ook merk ik dat de HD51 een dst_apply heeft.... en die is blijkbaar nodig om een verandering 'aktief' te maken... tenminste als je het via putty probeert aan te passen.... helemaal is het me niet duidelijk wat deze _apply doet,,,e

Dat hebben ze allemaal, dat is onderdeel van het mechanisme. Het lijkt er op dat het een volledige transactie afdwingt. Eerst alle gegevens in de entries echo'en en dan pas apply'en. Ik zou het zelf anders doen, met alle gegevens in één proc node, dan heb je dat probleem niet.

[littlesat]

Jammer dat transcode dan zo verstopt is en je dan 4K -OF- transcode hebt... want ik denk dat transcode meer toegevoegde waarde heeft dan PIP... Maar dat is mijn meening.... Maar we kunnen uiteraard Broadcom niet overtuigen... die zijn groter dan OpenPLi (LOL)...

 

En het klopt ook dat dat proc issue met het scherm naar beneden al ouder is en je af en toe ook zag bij de ET10K. Alleen is het veel erger geworden met gcc 6.0... (vanaf gcc 5.3 of zo kreeg je het zover ik begreep)... Kan iemand misschien testen of het op een ET10K met openpli5.0 nu ook persistent is?

 

is er "iets" waar ik kan beginnen met zoeken/doorspitten??? Kan het misschien zelfs zo zijn dat er drivers aangepast moeten worden voor dat nieuwere gcc spul?

 

De gekkigheid is dat het met mijn os.system work-a-round gewoon atlijd goed werkt... maar dat is zo bah! Ook als ik tussen de writes naar de procs een print commando stop (debug) gaat het ietsje "beter"... Duidelijk lijkt me dat een of andere race of zo...

 

En het gekke is dat die dst_apply niet altijd nodig is.... Maar dat maakt ook verder niets uit...

 

 

Ik zou het zelf anders doen, met alle gegevens in één proc node

 

Idd... gewoon een dst_position waar je left, top, width height na toe stuurt (e.g. 0,0,720,576 >dst_position) en dan ook nog gewoon decimaal,,, Helemaal mee eens, maar tja... wie zijn wij... ???

Het gebeurt wel met meerdere procs dat ze niet concequent zijn (enable/disable 1/0 on/off.... )... ooit is DMM met deze sjips begonnen

Edited by littlesat, 4 October 2016 - 14:53.

[Erik Slagter]

 

Zojuist een verse flash update gedaan en daarna de box een mode 12 gezet. En zie daar PiP support!

 

Ik ben er nog niet achter wat in de praktijk de nadelen zijn van deze mode.

 

Wellicht zal het energie verbruik iets stijgt omdat nu ook de derde video encoder gebruikt wordt voor PiP.

Gezien er nog geen OPUS en VP9 support is het nog onbekend of dit ook in mode 12 gaat werken.

Derde???

[Erik Slagter]

Littlesat, ik vind PiP nuttiger. Anyway, je kunt op deze manier kennelijk kiezen hoe de capaciteit van het sillicon verdeeld wordt, Broadcom en Mut@nt leggen je juist niks op. Je kunt net zo goed box mode 1 blijven gebruiken.

[littlesat]

Ik gebruik transcoding regelmatig en PIP eigenlijk nooit ... dus smaken verschillen...

 

Alleen 4K + transcoding gaat niet samen... dat is jammer... en zover ik de techniek begrijp niet nodig....

[WTE]

 

 

Zojuist een verse flash update gedaan en daarna de box een mode 12 gezet. En zie daar PiP support!

 

Ik ben er nog niet achter wat in de praktijk de nadelen zijn van deze mode.

 

Wellicht zal het energie verbruik iets stijgt omdat nu ook de derde video encoder gebruikt wordt voor PiP.

Gezien er nog geen OPUS en VP9 support is het nog onbekend of dit ook in mode 12 gaat werken.

Derde???

 

 

Ja "drie" zie eerder bericht: http://forums.openpl...ndpost&p=596221

[Erik Slagter]

Ja, daar zeg je twee encoders voor het main screen. Dat legt nog niet zoveel uit

[WTE]

Ja, daar zeg je twee encoders voor het main screen. Dat legt nog niet zoveel uit

 

Twee voor main en een derde voor PiP.

 

2160p heeft er twee nodig. Zo is het eenmaal opgebouwd bij de broadcom chips.

 

Wat er nog allemaal toekomstig mogelijk is met zoals "on the fly" wisselen van video encoders is afwachten.

Ik weet alleen niet als alle drie de video encoders hetzelfde zijn.

Zoals er al wordt gesuggereerd zou de derde ook voor transcode gebruikt kunnen worden. Helaas is dit optie (nog) niet mogelijk. 

[Erik Slagter]

Decoders bedoel je dus Bij encoder denk ik aan transcoding of aan een HDMI encoder.

 

Zal intern wel nets iets anders zitten dan twee echt discrete decoders, maar men heeft er kennelijk voor gekozen om het op deze manier te abstraheren.

 

Deze SoC wordt voor zover ik begrepen heb niet als "topmodel" in de markt gezet. Dus dan zullen er in de lengte of de breedte vast wel wat beperkingen zijn die gewoon niet even zijn op te lossen met andere firmware.

[littlesat]

Mmm ik krijg plotseling een idee waarom het schrijven naar die procs "apart" is...

 

je schrijft er o.a. 240 of zo naar toe... en dan komt er doodleuk 00000240 van terug...

 

ofwel 2D0 (720) en dan krijg je 000002d0 (kleine letter) terug...

 

Je schrijft naar een file en vervolgens komt er iets anders in die file dan je verwacht want die dingen zijn eigenlijk geen files...

 

"misschien" als je er naar schrijft wat je terug verwacht gaat het beter????

[Erik Slagter]

Littlesat, dat je dat zo ziet, is juist een GOED teken. Dat betekent dat je de waarde terugkrijgt zoals de driver die intern gebruikt. Als je precies dezelfde data terugkrijgt als dat je er in stopt, wat je bij de drivers van veel fabrikanten ziet (probeer maar eens "blah"), dan heb je geen enkele terugkoppeling of de driver er iets zinnigs van heeft weten te maken en of dat is wat je verwacht. Proc nodes zijn immers geen files!

[littlesat]

Klopt... helemaal gelijk in.... Maar naar de procs schrijven is eigenlijk hetzelfde als naar een file schrijven. En als de inhoud van die file 'door derden' veranderd wordt kan wel eens vreemde effecten hebben... Ik zal het vanavond eens testen/confirmeren....

 

En het klopt naar o.a. de VU drivers kan je alles "schrijven"... en laat nu net de "VU" boxen zover ik begrijp allen zeker wat betreft het std_ issue er geen last van hebben...

[Erik Slagter]

Het gaat mij er niet om of je er alles in "kunt" schrijven. Ik heb to zover alleen bij xtrend 3gen drivers gezien dat ongeldige waardes echt hard geweigerd worden met een Linux i/o error. Dat zou ik het liefst bij alle drivers zien, maar dat is Utopie. Eerstvolgend minder slechte insteek is dan tenminste de inhoud van de proc node vanuit de interne status van de driver genereren, in plaats van simpelweg terug echo'en wat er in gestopt is.

 

Even voor de duidelijkheid, bij proc nodes zit geen backing storage, er hangt een stukje code aan, geen file of andere opslag. Het is dus helemaal niet vanzelfsprekend dat je precies terugkrijgt wat je er in stopt, daarvoor moet men expliciet een stukje geheugen reserveren om de data in vast te houden. Niet echt de schoonheidsprijs.

[littlesat]

Ik heb in ieder geval test drivers gekregen van mut@nt en met deze drivers krijg je dat osd gedoe (dst_ spul) niet meer plat....

[Rob van der Does]

Ik heb in ieder geval test drivers gekregen van mut@nt en met deze drivers krijg je dat osd gedoe (dst_ spul) niet meer plat....

Die drivers zijn toch al twee dagen geleden vrijgegeven voor openbaar gebruik? Zie ook https://github.com/o...573c5388ba89a06 .

[littlesat]

Ben bang voor je dat ik toch andere drivers heb.... Nog net iets nieuwer....

Edited by littlesat, 7 October 2016 - 07:11.

[Rob van der Does]

Dus in de drivers waar ik naar verwees zit het OSD-position probleem toch nog?

 

PS: hoef je niet bang voor te zijn hoor

Edited by Rob van der Does, 7 October 2016 - 07:11.

[littlesat]

Hihi.... In de laatste drivers die ik heb weet ik ook nog niet 100% zeker dat het weg is.... Maar het erge is dat andere boxen er ook af en toe last vsn heben, en daar zitter er tussen die geen nieuwe drivers meer uitgeven...g

Ook zie ik dat de hd51 standaard rekening houd met overscan, dus het issue wordt sneller getriggert omdat e2 meteen die overscan weghaalt...

Edited by littlesat, 7 October 2016 - 07:13.

[Dimitrij]

openpli 4 vs1500


vs1500 login: root
root@vs1500:~# cat /sys/firmware/devicetree/base/bolt/tag
v1.07-r21root@vs1500:~#

v1.07-r21 Where from?