Talk:XMB Layouts: Difference between revisions
| Line 23: | Line 23: | ||
The way how works the XMB layout references inside rco files has been documented before, but the way how works inside the sprx files has been just an unproven theory since many time ago. This experiment is a sample of how it works, it throws an small ray of light at how the sprx files applyes "patches" over the [[RCOXML Objects]]<br> | The way how works the XMB layout references inside rco files has been documented before, but the way how works inside the sprx files has been just an unproven theory since many time ago. This experiment is a sample of how it works, it throws an small ray of light at how the sprx files applyes "patches" over the [[RCOXML Objects]]<br> | ||
The theory behind this experiment is based on the hipotesys that in between 4.88 and 4.99 there was maaaaany sprx files where the only thing that was updated in them is just a couple of bytes "here and there" that are the references to a line number of the XMB layout files, and the hipotesys that there are many times where the rco is storing the values inside the XMB layouts consecutivelly (so it could happen that the rco and the sprx could store all his values consecutivelly). So for this experiment it was needed to find a guinea pig where both, the sprx and the rco was updated in 4.89, also his function should be something trivial just to be sure sony was not trying to update anything important, and the last consideration was to find the files with the smallest size posible just to simplify the research with hexeditors/IDA... and the winner | The theory behind this experiment is based on the hipotesys that in between 4.88 and 4.99 there was maaaaany sprx files where the only thing that was updated in them is just a couple of bytes "here and there" that are the references to a line number of the XMB layout files, and the hipotesys that there are many times where the rco is storing the values inside the XMB layouts consecutivelly (so it could happen that the rco and the sprx could store all his values consecutivelly). So for this experiment it was needed to find a guinea pig where both, the sprx and the rco was updated in 4.89, also his function should be something trivial just to be sure sony was not trying to update anything important, and the last consideration was to find the files with the smallest size posible just to simplify the research with hexeditors/IDA... and the winner combos are... eula_hcopy_plugin.sprx (27 KB) / eula_hcopy_plugin.rco (60 KB)... and... eula_cddb_plugin.sprx (29 KB) / eula_cddb_plugin.rco (125 KB) | ||
The samples below are stripped versions from the main XML file generated by rcomage, where has been left only: the [[RCOXML Objects|RCOXML Object name]] (e.g: <IList>), the unique name (e.g: list_eula_start), and the attribute that difers in between 4.88 and 4.89 (the "overrides", responsibles of loading a value from a line of the XMB layout .txt files) | The samples below are stripped versions from the main XML file generated by rcomage, where has been left only: the [[RCOXML Objects|RCOXML Object name]] (e.g: <IList>), the unique name (e.g: list_eula_start), and the attribute that difers in between 4.88 and 4.89 (the "overrides", responsibles of loading a value from a line of the XMB layout .txt files) | ||
The references to the XMB layouts in the xml file generated by rcomage are in little endian, to convert them to "human readable" needs to be splitted in 2 chunks of 2 bytes each, first chunk is the "grid" and second chunk is the "factor". In this sample it can be seen how all the references to the "grid" was increased in +7 units | |||
In the "human readable" conversion for rco values im adding a +1 because in code the first line of a .txt file is line 0, but in a text editor the first line is 1... so im guessing is also neeed to do this +1 addition in the values from the sprx<br> | |||
XMB layout references in eula_hcopy_plugin.sprx 4.88 | XMB layout references in eula_hcopy_plugin.sprx 4.88 | ||
| Line 143: | Line 147: | ||
</syntaxhighlight>}} | </syntaxhighlight>}} | ||
In | In '''eula_hcopy_plugin.rco''' there are 11 attributes updated in total in between 4.88 and 4.89 but some of them contains the same hex value (for optimization purposes, are references to the same line in the XMB layout files). If we count only the unique values (to get an idea at how much lines this rco is using from the XMB layout files) we have a total of 6 references to the XMB layouts<br> | ||
If we count only the unique values (to get an idea at how much lines this rco is using from the XMB layout files) we have a total of 6 references to the XMB layouts | In '''eula_hcopy_plugin.prx''' (decrypted) there are 2 bytes that differs (that belongs to 2 values of 2 bytes length each). The 2 bytes updated in this sprx for 4.89 are the references to the XMB layouts, and both are a references to the same line number of the XMB layouts, so this sprx only stores a single value in the XMB layouts (located 3 lines before the values stored by the associated rco) | ||
In '''eula_cddb_plugin.rco''' there are 21 attributes updated in total in between 4.88 and 4.89 but some of them contains the same hex value (for optimization purposes, are references to the same line in the XMB layout files). If we count only the unique values (to get an idea at how much lines this rco is using from the XMB layout files) we have a total of 11 references to the XMB layouts<br> | |||
In | In '''eula_cddb_plugin.prx''' (decrypted) there are 12 bytes that differs (that belongs to 12 values of 2 bytes length each). The 12 bytes updated in this sprx for 4.89 are the references to the XMB layouts, but some are repeated, in total there are 5 unique references to the XMB layouts | ||
---- | ---- | ||
From this behaviour in the order of how the values are stored in the XMB layouts we can deduce that "the sprx stores first" (and the slave rco stores last) but maybe this is just a coincidence and not an strict rule | From this behaviour in the order of how the values are stored in the XMB layouts we can deduce that "the sprx stores first" (and the slave rco stores last) but maybe this is just a coincidence and not an strict rule | ||
Revision as of 01:31, 23 May 2022
Discussion/Speculation
Other images
The "XMB cross" also known as "XMB cursor". Is a position located always in the same place, defined in lines 258 and 259 of layout_factor_table_1080.txt. By changing the values to -750 and 200 the result is the whole XMB is displaced to the left-top corner https://www.youtube.com/watch?v=Tet5QwvGvgg
-395 35
Safety Notes
When making tests with this files keep in mind the safest ones are the modes your TV doesnt uses by default and/or remoteplay layouts because after a reboot the PS3 doesnt loads them (only loaded when enabling remote play from XMB, not at boot time)... also keep in mind that the other layouts should be common with the "recovery menu" and "service mode" display modes... and you can change your TV resolution in the options in XMB settings column, then return to default resolution with a button combo at boot time
Who is the owner ?
The values stored inside the layout.txt files are loaded by the rco files, every rco file could have tenths of references to load several values from the layout.txt files, and usually (but not always) this values are stored consecutivelly inside the layout.txt files. As example custom_render_plugin.rco from firmwares 4.80~4.89 is storing 6 values located consecutivelly at line numbers 665, 666, 667, 668, 669, 670. And the firmware 4.89 was added 7 new values located at lines 2580, 2581, 2582, 2583, 2584, 2585, 2586 of the layout_grid.txt files
In other words... every rco stores his values consecutivelly in the layout.txt files, but this process is not fully confirmed because it depends of the "optimizations" used by the sony compiler enviroment, the point is... if there are several RCOXML Objects inside the rco that requires to store the same value, then the compiler "should" store it a single time in the layout.txt files and force all the RCOXML Objects to load the same value from the same line in the layout.txt files. This would be optimal to minimize the size of the layout.txt files (and as far i remember sony does it sometimes) but we are not sure how stricts they was with his own rules and if there are other exceptions or rules used in this optimization. As another example... this optimization could be made not only with a single rco file but with all them together (this way the layout.txt files should contain only "unique" values, without any repetition). As far i remember sony is not doing it but is technically posible
One way or the other (with optimizations or without them)... we can see the order of the values of the list depends of the order of the rco files configured in the official sony compiler enviroment
It seems the compiler have a list with the names of the rco files that are going to be compiled, and the location of his values stored in the layout.txt files depends of that list. The rco file order of that list is completly unknown but IS NOT AN ALPHABETICAL ORDER, as example the file audioplayer_plugin.rco from 4.89 (the first rco in alphabeticall order loading values from the layout.txt files) is storing his values around line numbers 1500 (and custom_render_plugin.rco at line numbers 665)
The only good thing of the rco changes made in 4.89 (being optimistic), is one of the rco files was updated (probably was added a couple of RCOXML Objects, so his size in bytes increased a bit) and that objects required to store 7 new values at line 2580 of the layout_grid.txt files causing a displacement of +7 units in all the layout.txt references inside all the other rco files (the RCOXML attributes labeled in this wiki as "overrideSomething") that was storing his values over line 2580 (the displacement) in the layout.txt files
We are 99.9% sure that all the other rco files that was updated in 4.89 was a consequence of that displacement in the layout.txt files (the hex values that indicates a line from the layout.txt files was added +7 units)
In other words, all the rco files updated in 4.89 are storing his values over line 2580 of the layout.txt files (and the other rco files not updated are storing his values before line 2580 in the layout.txt files), thats a rought identification of his location inside the layout.txt files but better this than nothing
XMB layout references inside SPRX files
In between firmwares 4.88 and 4.89 sony made some minor changes to the XMB that required to update the source code of a couple of sprx files and the content of his associated rco files to add a couple of RCOXML Objects in them. The new RCOXML objects added for 4.89 required to store 7 new values at line 2580 (from a total of 4602 lines) in the XMB layout files. The new values added at an intermediate position of the XMB layout files caused a displacement of +7 units in all the references to the values located after line 2580 of the layout files. As a consequence of that displacement it was needed to update 76 sprx files and 43 rco files to increase in +7 units the XMB layout references inside them. See: 4.89 Changelog
The way how works the XMB layout references inside rco files has been documented before, but the way how works inside the sprx files has been just an unproven theory since many time ago. This experiment is a sample of how it works, it throws an small ray of light at how the sprx files applyes "patches" over the RCOXML Objects
The theory behind this experiment is based on the hipotesys that in between 4.88 and 4.99 there was maaaaany sprx files where the only thing that was updated in them is just a couple of bytes "here and there" that are the references to a line number of the XMB layout files, and the hipotesys that there are many times where the rco is storing the values inside the XMB layouts consecutivelly (so it could happen that the rco and the sprx could store all his values consecutivelly). So for this experiment it was needed to find a guinea pig where both, the sprx and the rco was updated in 4.89, also his function should be something trivial just to be sure sony was not trying to update anything important, and the last consideration was to find the files with the smallest size posible just to simplify the research with hexeditors/IDA... and the winner combos are... eula_hcopy_plugin.sprx (27 KB) / eula_hcopy_plugin.rco (60 KB)... and... eula_cddb_plugin.sprx (29 KB) / eula_cddb_plugin.rco (125 KB)
The samples below are stripped versions from the main XML file generated by rcomage, where has been left only: the RCOXML Object name (e.g: <IList>), the unique name (e.g: list_eula_start), and the attribute that difers in between 4.88 and 4.89 (the "overrides", responsibles of loading a value from a line of the XMB layout .txt files)
The references to the XMB layouts in the xml file generated by rcomage are in little endian, to convert them to "human readable" needs to be splitted in 2 chunks of 2 bytes each, first chunk is the "grid" and second chunk is the "factor". In this sample it can be seen how all the references to the "grid" was increased in +7 units
In the "human readable" conversion for rco values im adding a +1 because in code the first line of a .txt file is line 0, but in a text editor the first line is 1... so im guessing is also neeed to do this +1 addition in the values from the sprx
XMB layout references in eula_hcopy_plugin.sprx 4.88 offset:0x1C7E = 0x0D3C <--- line number 3389 ? offset:0x2EFA = 0x0D3C <--- line number 3389 ?
XMB layout references in eula_hcopy_plugin.rco 4.88 0x3f0d0100 <--- line number 3392 0x400d0100 <--- line number 3393 0x410d0100 <--- line number 3394 0x420d0100 <--- line number 3395 0xf7100100 <--- line number 4344 0xf9100100 <--- line number 4346
<IList name="list_eula_start" positionOverrideY="0x3f0d0100" sizeOverrideX="0x400d0100" sizeOverrideY="0x410d0100"> <Button name="button_eula_start_ok" positionOverrideY="0x420d0100"> <IList name="list_sync_trophy" positionOverrideY="0x3f0d0100" sizeOverrideX="0x400d0100" sizeOverrideY="0x410d0100"> <Button name="button_sync_trophy_yes" positionOverrideX="0xf7100100" positionOverrideY="0x420d0100"> <Button name="button_sync_trophy_no" positionOverrideX="0xf9100100" positionOverrideY="0x420d0100">
XMB layout references in eula_hcopy_plugin.sprx 4.89 offset:0x1C7E = 0x0D43 <--- line number 3396 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0x2EFA = 0x0D43 <--- line number 3396 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files)
XMB layout references in eula_hcopy_plugin.rco 4.89 0x460d0100 <--- line number 3399 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x470d0100 <--- line number 3400 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x480d0100 <--- line number 3401 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x490d0100 <--- line number 3402 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0xfe100100 <--- line number 4351 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x110100 <----- line number 4353 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
<IList name="list_eula_start" positionOverrideY="0x460d0100" sizeOverrideX="0x470d0100" sizeOverrideY="0x480d0100"> <Button name="button_eula_start_ok" positionOverrideY="0x490d0100"> <IList name="list_sync_trophy" positionOverrideY="0x460d0100" sizeOverrideX="0x470d0100" sizeOverrideY="0x480d0100"> <Button name="button_sync_trophy_yes" positionOverrideX="0xfe100100" positionOverrideY="0x490d0100"> <Button name="button_sync_trophy_no" positionOverrideX="0x110100" positionOverrideY="0x490d0100">
XMB layout references in eula_cddb_plugin.sprx 4.88 offset:0x3E5A = 0x0D3E <--- line number 3391 ? offset:0x421A = 0x0D3C <--- line number 3389 ? offset:0x5F66 = 0x0D27 <--- line number 3368 ? offset:0x5FB6 = 0x0D27 <--- line number 3368 ? offset:0x6206 = 0x0D26 <--- line number 3367 ? offset:0x624E = 0x0D26 <--- line number 3367 ? offset:0x630A = 0x0D26 <--- line number 3367 ? offset:0x634E = 0x0D26 <--- line number 3367 ? offset:0x9B92 = 0x0D26 <--- line number 3367 ? offset:0x9C0A = 0x0D26 <--- line number 3367 ? offset:0x9C82 = 0x0D26 <--- line number 3367 ? offset:0xADF2 = 0x0D3C <--- line number 3389 ?
XMB layout references in eula_cddb_plugin.rco 4.88 0x280d0100 <--- line number 3369 0x290d0100 <--- line number 3370 0x2a0d0100 <--- line number 3371 0x2b0d0100 <--- line number 3372 0x2c0d0100 <--- line number 3373 0x350d0100 <--- line number 3382 0x360d0100 <--- line number 3383 0x3f0d0100 <--- line number 3392 0x400d0100 <--- line number 3393 0x410d0100 <--- line number 3394 0x420d0100 <--- line number 3395
<Plane name="plane_eula_licensing_wizard_arrow_back" positionOverrideX="0x280d0100" sizeOverrideX="0x2b0d0100" sizeOverrideY="0x2c0d0100"> <Plane name="plane_eula_licensing_wizard_arrow_shadow_back" positionOverrideY="0x2a0d0100" sizeOverrideX="0x2b0d0100" sizeOverrideY="0x2c0d0100"> <Plane name="plane_eula_licensing_wizard_arrow_next" positionOverrideX="0x290d0100" sizeOverrideX="0x2b0d0100" sizeOverrideY="0x2c0d0100"> <Plane name="plane_eula_licensing_wizard_arrow_shadow_next" positionOverrideY="0x2a0d0100" sizeOverrideX="0x2b0d0100" sizeOverrideY="0x2c0d0100"> <IList name="licensing_inspection_list" positionOverrideY="0x3f0d0100" sizeOverrideX="0x400d0100" sizeOverrideY="0x410d0100"> <Text name="licensing_option_choice_title" sizeOverrideX="0x350d0100" sizeOverrideY="0x360d0100"> <IList name="list_long_mongon_view" positionOverrideY="0x3f0d0100" sizeOverrideX="0x400d0100" sizeOverrideY="0x410d0100"> <Button name="button_long_mongon_view" positionOverrideY="0x420d0100">
XMB layout references in eula_cddb_plugin.sprx 4.89 offset:0x3E5A = 0x0D45 <--- line number 3398 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0x421A = 0x0D43 <--- line number 3396 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0x5F66 = 0x0D2E <--- line number 3375 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0x5FB6 = 0x0D2E <--- line number 3375 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0x6206 = 0x0D2D <--- line number 3374 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0x624E = 0x0D2D <--- line number 3374 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0x630A = 0x0D2D <--- line number 3374 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0x634E = 0x0D2D <--- line number 3374 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0x9B92 = 0x0D2D <--- line number 3374 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0x9C0A = 0x0D2D <--- line number 3374 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0x9C82 = 0x0D2D <--- line number 3374 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files) offset:0xADF2 = 0x0D43 <--- line number 3396 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files)
XMB layout references in eula_cddb_plugin.rco 4.89 0x2f0d0100 <--- line number 3376 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x300d0100 <--- line number 3377 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x310d0100 <--- line number 3378 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x320d0100 <--- line number 3379 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x330d0100 <--- line number 3380 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x3c0d0100 <--- line number 3389 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x3d0d0100 <--- line number 3390 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x460d0100 <--- line number 3399 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x470d0100 <--- line number 3400 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x480d0100 <--- line number 3401 (increased in +7 units, as a consequence of the displacement in the XMB layout files) 0x490d0100 <--- line number 3402 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
<Plane name="plane_eula_licensing_wizard_arrow_back" positionOverrideX="0x2f0d0100" sizeOverrideX="0x320d0100" sizeOverrideY="0x330d0100"> <Plane name="plane_eula_licensing_wizard_arrow_shadow_back" positionOverrideY="0x310d0100" sizeOverrideX="0x320d0100" sizeOverrideY="0x330d0100"> <Plane name="plane_eula_licensing_wizard_arrow_next" positionOverrideX="0x300d0100" sizeOverrideX="0x320d0100" sizeOverrideY="0x330d0100"> <Plane name="plane_eula_licensing_wizard_arrow_shadow_next" positionOverrideY="0x310d0100" sizeOverrideX="0x320d0100" sizeOverrideY="0x330d0100"> <IList name="licensing_inspection_list" positionOverrideY="0x460d0100" sizeOverrideX="0x470d0100" sizeOverrideY="0x480d0100"> <Text name="licensing_option_choice_title" sizeOverrideX="0x3c0d0100" sizeOverrideY="0x3d0d0100"> <IList name="list_long_mongon_view" positionOverrideY="0x460d0100" sizeOverrideX="0x470d0100" sizeOverrideY="0x480d0100"> <Button name="button_long_mongon_view" positionOverrideY="0x490d0100">
In eula_hcopy_plugin.rco there are 11 attributes updated in total in between 4.88 and 4.89 but some of them contains the same hex value (for optimization purposes, are references to the same line in the XMB layout files). If we count only the unique values (to get an idea at how much lines this rco is using from the XMB layout files) we have a total of 6 references to the XMB layouts
In eula_hcopy_plugin.prx (decrypted) there are 2 bytes that differs (that belongs to 2 values of 2 bytes length each). The 2 bytes updated in this sprx for 4.89 are the references to the XMB layouts, and both are a references to the same line number of the XMB layouts, so this sprx only stores a single value in the XMB layouts (located 3 lines before the values stored by the associated rco)
In eula_cddb_plugin.rco there are 21 attributes updated in total in between 4.88 and 4.89 but some of them contains the same hex value (for optimization purposes, are references to the same line in the XMB layout files). If we count only the unique values (to get an idea at how much lines this rco is using from the XMB layout files) we have a total of 11 references to the XMB layouts
In eula_cddb_plugin.prx (decrypted) there are 12 bytes that differs (that belongs to 12 values of 2 bytes length each). The 12 bytes updated in this sprx for 4.89 are the references to the XMB layouts, but some are repeated, in total there are 5 unique references to the XMB layouts
From this behaviour in the order of how the values are stored in the XMB layouts we can deduce that "the sprx stores first" (and the slave rco stores last) but maybe this is just a coincidence and not an strict rule