Editing Talk:XMB Layouts

==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|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<br>
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<br>
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<br>
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 <b>IS NOT AN ALPHABETICAL ORDER</b>, 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)<br>
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<br>
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)<br>
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<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 last consideration is to find the files with the smallest size posible just to simplify the research with hexeditors/IDA... and the winner combo is... eula_hcopy_plugin.sprx (27 KB) / eula_hcopy_plugin.rco (60 KB)

The samples below are stripped version 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 attrobute 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)

{{Boxcode|title=eula_hcopy_plugin.rco (4.88)|code=<syntaxhighlight lang="xml">
<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">
</syntaxhighlight>}}

{{Boxcode|title=eula_hcopy_plugin.rco (4.89)|code=<syntaxhighlight lang="xml">
<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">
</syntaxhighlight>}}

In total there are 11 attributes updated in between 4.88 and 4.89 in eula_hcopy_plugin.rco 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

 XMB layout references in 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

 XMB layout references in 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)

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<br>
In firmware 4.89 this rco is storing 4 values consecutivelly at lines 3399, 3400, 3401, 3402. And additionally is storing another 2 values at lines 4351 and 4353 (not consecutivelly, there is a gap in between them used by something else)

----
When comparing the (decrypted) 4.88 and 4.89 versions of eula_hcopy_plugin.sprx there are only 2 bytes that differs (that belongs to 2 values of 2 bytes length each)
 offset:0x1C7E = 0x0D3C
 offset:0x2EFA = 0x0D43