Hi folks. I've been having a bit of a hack to try and get MMS messages backed up. Now I know why it hasn't been done before ;-)
I've written a program that dumps cemail.vol into an xml file. It lists all the records in all the databases, and lists all properties per row. It even makes a best attempt at guessing the MAPI property name of each property is (they match to all the PR_ constants, just with certain MAPI type identifiers changed for the matching EDB type).
So, from my database dump, I've got a pmailMsgClasses database that lists all the known IPM.Whatever types, such as IPM.SMStext and IPM.MMS. Then there's the pmailFolders database that lists the hierarchy of folders, from IPM.Root to accounts(/MsgStores) such as SMS, ActiveSync and MMS to actual folders, such as Inbox, Drafts, etc.
Then there's the pmailMsgs database, which lists every single message in the system. There's not much data in here, but there's a pointer to the oid of the MsgStore (e.g. MMS), and an oid of the folder the message is in (e.g. Drafts). There are other properties, including a couple of binary ones, but nothing really interesting apart from another oid that links to a record in a fldrXXXXXXXX database, where the XXXXXXXX is replaced with a hex representation of the oid of the (e.g. Drafts) folder.
This fldr database contains more information about the message, including sender details, receive time, message time, message class (e.g. IPM.MMS) and subject.
For SMS messages, the contents of the message are actually stored in the subject property. I don't have any emails in my system, so I don't know what happens here, but for MMS, there is no indication of the content.
If we go spelunking on the file system, we find \My Documents\UAContents and a whole load of *.dat files. These files are your MMS messages. They all have numerical filenames such as 21420.dat. The filesize of these matches the message size property in the database. When you edit or view an MMS, the .dat file is expanded - a directory is created with the same name as the file without the .dat (e.g. 21420) and the images, text and html is saved as separate files.
My problem is, I can't find any kind of link between the messages in the database and these files in the file system! Does anyone have any ideas?
(I have figured out the .mpb files stored in \Windows\Messaging though. I think this is where the body property is stored. The filename is something like a23c00031000001f.mpb. The 1000001f is the value of PR_BODY, and the a23c0003 maps to the oid of the message in pmailMsg - 0x3c0003a2. Unfortunately, these aren't created for MMS.)
As an example, my MMS drafts folder has an oid of 0x31000031. This means I have a database called fldr31000031. In pmailMsgs, I have a record with oid 0x30000363. This contains a property whose value is an oid of 0x350003ed, which is a record in the fldr3100000031 database. And the contents of this message are stored in 24120.dat. This is 5E38 in hex (all .dat files map nicely to 4 digit hex numbers), but I can't see the connection between these. Anyone?
Cheers
Matt
Some example data for message 24120.dat:
Code:
<database name="fldr31000031"> <!-- 0x31000031 is MMS drafts -->
...
<record index="2" oid="0x350003ed" numProps="13">
<prop index="1" cepropid="0x80050013" mapiPropName="ParentOid?" propType="CEVT_UI4" >0x30000363</prop> <!-- oid of record in pmailMsgs -->
<prop index="2" cepropid="0x80110013" propType="CEVT_UI4" >0x0000000e</prop>
<prop index="3" cepropid="0xc1f001f" mapiPropName="PR_SENDER_EMAIL_ADDRESS" propType="CEVT_LPWSTR" ><![CDATA[]]></prop>
<prop index="4" cepropid="0xc1a001f" mapiPropName="PR_SENDER_NAME" propType="CEVT_LPWSTR" ><![CDATA[]]></prop>
<prop index="5" cepropid="0xe170013" mapiPropNameWithUnexpectedType="PR_MSG_STATUS" propType="CEVT_UI4" >0x00000000</prop>
<prop index="6" cepropid="0xe060040" mapiPropName="PR_MESSAGE_DELIVERY_TIME" propType="CEVT_FILETIME" >High=0x1c7f88a Low=0xc5241500 (2007-09-16T17:55:30.0000Z)</prop>
<prop index="7" cepropid="0x1a0013" mapiPropNameWithUnexpectedType="PR_MESSAGE_CLASS" propType="CEVT_UI4" >0x330000d7</prop> <!-- IPM.MMS1 in pmailMsgClasses -->
<prop index="8" cepropid="0x3d001f" mapiPropName="PR_SUBJECT_PREFIX" propType="CEVT_LPWSTR" ><![CDATA[]]></prop>
<prop index="9" cepropid="0x37001f" mapiPropName="PR_SUBJECT" propType="CEVT_LPWSTR" ><![CDATA[Subject text]]></prop>
<prop index="10" cepropid="0xe080013" mapiPropNameWithUnexpectedType="PR_MESSAGE_SIZE" propType="CEVT_UI4" >0x0000022a</prop> <!-- 554 bytes -->
<prop index="11" cepropid="0x80010013" mapiPropName="OwnOid" propType="CEVT_UI4" >0x350003ed</prop>
<prop index="12" cepropid="0xe070013" mapiPropNameWithUnexpectedType="PR_MESSAGE_FLAGS" propType="CEVT_UI4" >0x10000028</prop>
<prop index="13" cepropid="0x30080040" mapiPropName="PR_LAST_MODIFICATION_TIME" propType="CEVT_FILETIME" >High=0x1c7ff6c Low=0xc4673f00 (2007-09-25T12:08:22.0000Z)</prop>
</record>
...
</database>
and
Code:
<database name="pmailMsgs">
...
<record index="151" oid="0x30000363" numProps="17">
<prop index="1" cepropid="0x80010013" mapiPropName="OwnOid" propType="CEVT_UI4" >0x30000363</prop>
<prop index="2" cepropid="0x80080013" propType="CEVT_UI4" >0x00000001</prop>
<prop index="3" cepropid="0x80040013" propType="CEVT_UI4" >0x00000000</prop>
<prop index="4" cepropid="0x80030013" propType="CEVT_UI4" >0x00000000</prop>
<prop index="5" cepropid="0x80090013" propType="CEVT_UI4" >0x00000000</prop>
<prop index="6" cepropid="0x800a0013" propType="CEVT_UI4" >0x00000000</prop>
<prop index="7" cepropid="0x800c001f" mapiPropName="SenderPhoneNumber?" propType="CEVT_LPWSTR" ><![CDATA[]]></prop>
<prop index="8" cepropid="0x800d001f" propType="CEVT_LPWSTR" ><![CDATA[]]></prop>
<prop index="9" cepropid="0x800e001f" propType="CEVT_LPWSTR" ><![CDATA[]]></prop>
<prop index="10" cepropid="0x800f001f" propType="CEVT_LPWSTR" ><![CDATA[]]></prop>
<prop index="11" cepropid="0x8010001f" propType="CEVT_LPWSTR" ><![CDATA[]]></prop>
<prop index="12" cepropid="0x8011001f" propType="CEVT_LPWSTR" ><![CDATA[]]></prop>
<prop index="13" cepropid="0x800e0041" propType="CEVT_BLOB" ><binaryData length="20">14 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 84 2b 08 00 </binaryData></prop> <!-- 0x14 is size of blob -->
<prop index="14" cepropid="0x80010041" mapiPropNameWithUnexpectedType="OwnOid" propType="CEVT_BLOB" ><binaryData length="48">00 80 81 81 19 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 63 00 75 00 00 00 00 00 00 00 00 00 00 00 00 00 55 00 41 00 43 00 6f 00 </binaryData></prop> <!-- Ends in UACo? -->
<prop index="15" cepropid="0x80060013" mapiPropName="MessageOid?" propType="CEVT_UI4" >0x350003ed</prop> <!-- oid for message in fldrxxx -->
<prop index="16" cepropid="0xe090013" mapiPropNameWithUnexpectedType="PR_PARENT_ENTRYID" propType="CEVT_UI4" >0x31000031</prop> <!-- Drafts -->
<prop index="17" cepropid="0x80110013" propType="CEVT_UI4" >0x3000002b</prop> <!-- MsgStore oid -->
</record>
...
</database>
Interesting!
Hi!
Nice Job!
I'm bound to admit that I'm very interested in what you did. Is it possible you make it available on this forum?
Thks.
Systemfailure
Related
Okay, so I've tried everything. PDOCREAD, DUMPROM, pget, grab_it, testdump.exe, FiziFetch. I need help with getting at all of the files and doing a complete ROM dump of the device. The only ROM Dump I have is the one that ETEN provides for upgrading the phone, I have attached that here. EUU.exe is the exe you run on the pc, and normally the rom file is called temp.dat, and it uses the other .exe which is compiled for windows ce to the phone to do the updating process.
Any help here would be greatly appreciated. In particular I want btagext.dll in the /Windows directory and full instructions on how to do it myself for other protected files.
The ROM can be obtained by going to updates.eten.ch and downloading the latest English ROM file for the M600. The direct link is here:
ftp://support.com:[email protected]/Download/Updates/M600/ENG/EUU_M600_WWE_R01_100_0171.EXE
To get the ROM file and the update file, goto your documents and settings/profile name/local settings/temp folder and clear out all the files.
Run the .exe you downloaded from above, and then look in the temp folder you just cleared. You should see a temp.dat which is the ROM file, EUU.exe which is the file that facilitates the transfer of the file to the ETEN M600 and another file USBDLUpdate_Console.exe which is a windows CE compiled file that facilitates the flashing process in some way.
Pdocread part of the itsutils is able to read see some of the information on my device:
pdocread –l lists the following:
122.19M FLASHDR
| 1.03M Part00
| 1.52M Part01
| 33.98M Part02
| 85.47M Part03
1.89G DSK1:
| 1.89G SD
STRG handles: a34cc21e
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
( 1.89G) e3b41b8a
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
( 85.47M) e3b4153e
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
( 33.98M) 83b41436
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
( 1.52M) a3b412be
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
( 1.03M)
However it is not able to do anything other then that. All attempts at trying to access those partitions or device (flashdr) fail with errors such as these (this is just a small list of commands command options i've tried):
C:\itsutils\build>pdocread -d DSK1
ERROR: ITTFFSGetInfo - The handle is invalid.
C:\itsutils\build>pdocread -d DSK1:
ERROR: ITLogDiskInfo - An exception occurred in the service when handling the co
ntrol request.
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
C:\itsutils\build>pdocread 0x0 0x200 foo.bin
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CopyTFFSToFile(0x0, 0x200, foo.bin)
ERROR: ITReadDisk - An internal error occurred.
C:\itsutils\build>pdocread -o -p part03
ERROR: ITTFFSGetInfo: outbuf==NULL
WARNING: using default 512 bytes for sectorsize
C:\itsutils\build>pdocread -d FLASHDR -w
ERROR: ITTFFSGetInfo - The handle is invalid.
Re: Need help extracting files from ETEN M600 ROM will pay $
I don't think that you'll be able to get a working dump of btagext.dll or any other system DLL. It does not have relocation information.
temp.dat in eten upgrade is in some strange format, it seems that data blocks are mixed.
What is the result of testdump.exe? I've attached the WM5 build of this program.
Re: Need help extracting files from ETEN M600 ROM will pay $
I've tried that before. That just dumps some information that is in memory. You can see calendar information, contact information, etc. If you put in 128mb which is the ROM size, it says DUMP OK this time (it had filesys errors the time I tried it a couple weeks ago) See here:
http://www.eten-users.net/topic1085
Anyways, in the end it dumps a 64 meg file instead of the 128 you specified, which is just the stuff in memory the 64 megs of RAM that this thing is suppose to have. If you use romdump on that file it doesn't get to many files, just about 30 or so and none of them are very important (most you can get via windows explorer and activesync)
FB
Re: Need help extracting files from ETEN M600 ROM will pay $
why do you think that eten has 128Mb OS ROM? It has only 48Mb ROM, other is left to persistent storage. So these tools would never dump full 128Mb, only 64Mb max.
You should upload somewhere the output of testdump tool, so I can look at it. It should produce _correct_ ROM dump. You just cannot extract files from it correctly. "dumprom" is for older oses, and with "-5" switch it would extract only files from XIP section (about 20 files). Use my "viewimgfs" tool to get everything from IMGFS.
I looked in the control panel, you are right it appears that the system part takes up about 48 mb, with the rest of the 128mb as user storage. It's kind of wierd though that testdump would stop at 64mb, wouldn't it stop at 48mb instead? If not why is it not doing the full 128 mb.
I tried what you had suggested and unfortunately that doesn't work either. I dumped a 64mb image, and a 48mb image. viewimgfs.exe didn't work on those images. I tried prepimgfs on the 48mb one and it couldn't find imgfs start location. I tried it on the 64mb one and it found it but the resulting file was about 256kb with a 4kb "removed_data" file which is definately not right.
I tried it without first running prepareimgfs and it just says "unable to load compress .dll".
I can't send a rom dump of what I have yet as it contains all of my contacts and calender information in looking at the memory dump in a hex editor, I'll have to whip the device clean again and I can send one but that may take awhile, i've got a lot of stuff setup right now.
Any other suggestions?
I found another bit of information. I played around with MTTY, which I know is for HTC devices, just to see what it would do though I thought I would try. It connects to the bootloader, however you never get to a command prompt. It appears that i can send a command, but then it trys to just download a file (the updated ROM). So I'm not sure if anything else can be done with this, I was hoping I could do something like "d2s" but it appears that with MTTY that doesn't seem possible.
I'm wondering if there is some way to map a USB port to a COM port so I can use regular hyperterminal. Does anyone know how to do this as Hyperterminal only supports COM ports...
MTTY is identical to hyperterminal
Ahh okay, it must be that they haven't implemented a nice interface like HTC devices where you can issue all of those commands
Hi!
Until now can you dump it? I can help you dump....
PM me,OK?
Okay, so i've finally been able to get these files from Vijay, however I'm still running into issues as describe here:
http://www.eten-users.net/topic1500
Anyone have any information on how to reconstruct PE files?
Hi, anyone could please upload there mediaPlayer ButtonMap preferences registry enry? eg fastforward and their corresponding data value (eg FastForward data is 27 00 00 00 02 00 00 00... and if anyone tried mapping thier headset button, please post for the data value eg (Next data is ?? ?? ?? ?? ?? ?? ??) thanks...
Hi folks,
i've been reading quite a bit here, but found nothing real specific for dumping a original rom of the polaris. could someone please state a little howto, like for the other devices? or can other howtows (eg: dumping elf rom) be used for the polaris ?
thanks a lot....
seminiox said:
Hi folks,
i've been reading quite a bit here, but found nothing real specific for dumping a original rom of the polaris. could someone please state a little howto, like for the other devices? or can other howtows (eg: dumping elf rom) be used for the polaris ?
thanks a lot....
Click to expand...
Click to collapse
found with search...
http://forum.xda-developers.com/showpost.php?p=1847607&postcount=13
cheers!
thanx for your answer, will try to make a backup now.....
cu
ok, i extracted the 4 files, part00-04.raw. how can i create a file to flash for my device ?
seminiox said:
ok, i extracted the 4 files, part00-04.raw. how can i create a file to flash for my device ?
Click to expand...
Click to collapse
And do you want a coffee?
do you know how to search in this board ?
Just found with search function..........
http://wiki.xda-developers.com/index.php?pagename=Elf_HowtoDumpRom
bye
ouioui01 said:
And do you want a coffee?
do you know how to search in this board ?
Just found with search function..........
http://wiki.xda-developers.com/index.php?pagename=Elf_HowtoDumpRom
bye
Click to expand...
Click to collapse
well sorry for that, i have just been not shure if the description for an elf will work on my polaris. but still got some new question:
i first did a hardspl. to create an archive the guide says is have to:
take the extracted 05_OS.nb as shell/template for your ROMdump, will be overwritten!
D:\_ROM>make_imgfs.exe 05_OS.nb -nosplit
Searching for IMGFS start... Found at 00620000
Fixing... Done!
which can be extracted from
the ruu_signed.nbh from valid RUU_update.exe
so, if i don't have a valid ruu_update.exe (with original german xda orbit2 rom) i have no possibility to follow the instructions...... ???
I'm in the same boat. I want a "clean" orbit 2 but, as we all know, any O2 shop will a) give me **** and b) ask me for a lot of money if I arrive with a custom-flashed orbit 2 I want repaired.
The guide looks good, but isnt really tailored for the current Polaris situation, is it?
From what I know, I guess that I can just take the generic HTC Polaris WWE on the FTP as a signed template and compile my backup ROM that way, right?
And last question: will that revert olis HardSPL too?
schaggo said:
And last question: will that revert olis HardSPL too?
Click to expand...
Click to collapse
not with my device
I also would like to know, if the files provided here
http://wiki.xda-developers.com/index...f_HowtoDumpRom
are lgood to dump my original polaris rom?
Did someone ldo that already?
A step by step guide how to ldump my original polaris rom lwould be great...
Dumping a ROM isnt the problem. Getting the slightly branded/altered O2 ROM (in perspective to the original HTC factory Polaris ROM) back onto the device without an original O2 Updater is going to be the problem, right?
Since the HTC 1.25.405.1 Updater doesnt equal an (whenever it arrives) O2 Updater, right?
So compiling a backup ROM consisting of the currently available HTC WWE Updater and my Orbit 2 ROM backup is going to result in a device which could be identified as a Touch Cruise with O2 ROM extentions and not an original Orbit 2 with an O2 ROM, right?
I tried to dump according the wiki, but it looks different. (see below)
There seem to be some errors. Can anyone help?
D:\rom>pdocread.exe -l
210.88M (0xd2e0000) FLASHDR
| 3.12M (0x31f000) Part00
| 3.75M (0x3c0000) Part01
| 86.00M (0x5600000) Part02
| 118.00M (0x7600000) Part03
7.61G (0x1e6e80000) DSK1:
| 7.60G (0x1e6a80000) Part00
STRG handles:
handle 85ba9956 7.60G (0x1e6a80000)
handle 873ff0f6118.00M (0x7600000)
handle 874995a6 86.00M (0x5600000)
handle 47499582 3.75M (0x3c0000)
handle a74993b2 3.12M (0x31f000)
disk 85ba9956
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk 873ff0f6
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk 874995a6
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk 47499582
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk a74993b2
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
D:\rom>pdocread -w -d TrueFFS -p Part02 -t
ERROR: ITTFFSGetInfo - Das Gerõt kann nicht verwendet werden.
WARNING: using default 512 bytes for sectorsize
real nr of sectors: 1 - 512.00byte (0x200)
D:\rom>
http://forum.xda-developers.com/showpost.php?p=1923718&postcount=121
What is this key? It was found by navigating to*#*#4636#*#*
Interesting find I too wonder what it is
Sent from my LEX727 using Tapatalk
HewettBR said:
What is this key?
Click to expand...
Click to collapse
I've no idea yet what it's used for, but I can tell you where it is stored:
The full key is stored in the partition "letvconfig":
Code:
/dev/block/bootdevice/by-name/letvconfig
While the total size of the partition is 524288 bytes (= exactly 512K) only the first 32 bytes seem to contain this LeKey and the remaining 524256 bytes are all zero.
When you are root you can easily dump this partition via adb shell:
Code:
# dd if=/dev/block/bootdevice/by-name/letvconfig of=/sdcard/letvconfig.img bs=512
And display the content with hexdump (or any other hex-editor):
Code:
# hexdump -C /sdcard/letvconfig.img
00000000 62 35 .......................................... |b5a4xxxxxxxxxxxx|
00000010 ....................................... 33 33 36 |xxxxxxxxxxxxc336|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
(Note that I replaced my actual code with "........" and "xxxxx" here as I don't want to post it in public.)
androcheck said:
I've no idea yet what it's used for, but I can tell you where it is stored:
The full key is stored in the partition "letvconfig":
Code:
/dev/block/bootdevice/by-name/letvconfig
While the total size of the partition is 524288 bytes (= exactly 512K) only the first 32 bytes seem to contain this LeKey and the remaining 524256 bytes are all zero.
When you are root you can easily dump this partition via adb shell:
Code:
# dd if=/dev/block/bootdevice/by-name/letvconfig of=/sdcard/letvconfig.img bs=512
And display the content with hexdump (or any other hex-editor):
Code:
# hexdump -C /sdcard/letvconfig.img
00000000 62 35 .......................................... |b5a4xxxxxxxxxxxx|
00000010 ....................................... 33 33 36 |xxxxxxxxxxxxc336|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
(Note that I replaced my actual code with "........" and "xxxxx" here as I don't want to post it in public.)
Click to expand...
Click to collapse
Is this key used to play with bootloader?
I am having a le Pro 3 AI and i am unable to save my unlock settings on bootloader / use baseband with unlocked bootloader. But what i do find is their bootloader has a fastboot command.
fastboot oem key
may be that can give us more access.May be , just assuming , this key can provide access to more features?
prateekkej said:
Is this key used to play with bootloader?
fastboot oem key
may be that can give us more access.May be , just assuming , this key can provide access to more features?
Click to expand...
Click to collapse
Great idea, I also think that this key can be useful.
I'm also having AI, so if you'll find a way to use a key with our device to make some profitable unlock, please update me to.
Browsing through the kernel source, I got very curious about the flag "qcom,mdss-dsi-panel-inverted" being commented out in this file:
https://github.com/OnePlusOSS/andro...qcom/dsi-panel-samsung_s6e3fa5_1080p_cmd.dtsi
Could an experimented kernel builder create a kernel with this flag enabled, and check if the refresh direction of the panel changes, or the jello effect is diminished ?
I don't want to unlock my bootloader just yet
Hmmm.... Interesting...
maybe we will end up with a 180° inverted display.
Watching the thread
paratox said:
maybe we will end up with a 180° inverted display.
Click to expand...
Click to collapse
That is easy to fix in software though The HW is a *****
This flag is not in the documentation, it is not mentioned anywhere else in the kernel source, only oneplus devices have it in their source. For the prop to actually be readable it needs to be recognized in other parts of the kernel like this.
So, at best, the device will boot with no changes because the flag won't be recognized.
Flar2 mentioned that this change doesn't impact jelly affect...
ram4ufriends said:
Flar2 mentioned that this change doesn't impact jelly affect...
Click to expand...
Click to collapse
nah he just said "It doesn't seem to make any difference"
and the second response is "I'm not sure. I think if it was easily fixed, OnePlus would fix it in an update."
thats all
dukat0s said:
nah he just said "It doesn't seem to make any difference"
and the second response is "I'm not sure. I think if it was easily fixed, OnePlus would fix it in an update."
thats all
Click to expand...
Click to collapse
Which means that flag fix didn't work, isn't it?
ram4ufriends said:
Which means that flag fix didn't work, isn't it?
Click to expand...
Click to collapse
? what " flag fix" u talking about ? : >
ram4ufriends said:
Which means that flag fix didn't work, isn't it?
Click to expand...
Click to collapse
I know what you mean and no, it didn't work.
ZakooZ said:
This flag is not in the documentation, it is not mentioned anywhere else in the kernel source, only oneplus devices have it in their source. For the prop to actually be readable it needs to be recognized in other parts of the kernel like this.
So, at best, the device will boot with no changes because the flag won't be recognized.
Click to expand...
Click to collapse
Fair enough, I didn't check whenever this symbol is further referenced. Moreover, in MIPI DCS language, 'inverted' refers to 'color-inverted' display, not 'orientation-inverted'.
So I got curious, and took the DTSi file for the panel and the patch to enable the closely related S6E3FA0 panel on Exynos (never made it upstream), and decoded the `qcom,mdss-dsi-on-command` sequence, since it seems the best place to insert a command to rotate the display, if it exists; my decoding is below (references https://www.tonylabs.com/wp-content/uploads/MIPI_DCS_specification_v1.02.00.pdf)
Code:
.1 .2 .3 .4 .5 .6 .7 .8 .9 # decode of byte .8
#=============================================
05 01 00 00 14 00 02 11 00 # DCS exit_sleep_mode
15 01 00 00 00 00 02 35 00 # DCS set_tear_on
39 01 00 00 00 00 03 F0 5A 5A # MCS_KEY_LEV1
39 01 00 00 00 00 02 B0 04 # MCS_GLOBAL_PARAMETER
39 01 00 00 00 00 04 B4 06 0C 12 # ?? undocumented
39 01 00 00 00 00 03 F0 A5 A5 # MCS_KEY_LEV1
15 01 00 00 00 00 02 53 20 # ?? undocumented
15 01 00 00 00 00 02 55 00 # ?? DCS_WRITE_CABC
39 01 00 00 00 00 03 F0 5A 5A # MCS_KEY_LEV1
39 01 00 00 00 00 02 C3 01 # ?? undocumented
39 01 00 00 00 00 02 B0 18 # MCS_GLOBAL_PARAMETER
39 01 00 00 00 00 02 C3 00 # ?? undocumented
39 01 00 00 00 00 03 F0 A5 A5 # MCS_KEY_LEV1
05 01 00 00 00 00 02 29 00 # DCS set_display_on
In the MIPI DCS specification, one can control the Device Line Refresh Order:
1155 Bit B4 – Display Device Line Refresh Order
1156 This bit controls the display device’s horizontal line refresh order. The image shown on the display device
1157 is unaffected, regardless of the bit setting.
1158 ‘0’ = Display device is refreshed from the top line to the bottom line
1159 ‘1’ = Display device is refreshed from the bottom line to the top line
Click to expand...
Click to collapse
Things I would try:
Find Samsung references for the display controller so we can find the undocumented commands below
Use command DCS set_address_mode 36h to flip the display: insert before the last line:
Code:
15 01 00 00 00 00 02 36 10
or
Code:
15 01 00 00 00 00 02 36 00
and see what we get on display and if we can change the refresh direction. In worst case, we need to try all values from 00 for FF for the last byte in the command.
Anybody with a unlocked bootloader and time to recompile the kernel to test this ?
ddalex said:
Fair enough, I didn't check whenever this symbol is further referenced. Moreover, in MIPI DCS language, 'inverted' refers to 'color-inverted' display, not 'orientation-inverted'.
So I got curious, and took the DTSi file for the panel and the patch to enable the closely related S6E3FA0 panel on Exynos (never made it upstream), and decoded the `qcom,mdss-dsi-on-command` sequence, since it seems the best place to insert a command to rotate the display, if it exists; my decoding is below (references https://www.tonylabs.com/wp-content/uploads/MIPI_DCS_specification_v1.02.00.pdf)
In the MIPI DCS specification, one can control the Device Line Refresh Order:
1155 Bit B4 – Display Device Line Refresh Order
1156 This bit controls the display device’s horizontal line refresh order. The image shown on the display device
1157 is unaffected, regardless of the bit setting.
1158 ‘0’ = Display device is refreshed from the top line to the bottom line
1159 ‘1’ = Display device is refreshed from the bottom line to the top line
Things I would try:
Find Samsung references for the display controller so we can find the undocumented commands below
Use command DCS set_address_mode 36h to flip the display: insert before the last line:
Things I would try:
Find Samsung references for the display controller so we can find the undocumented commands below
Use command DCS set_address_mode 36h to flip the display: insert before the last line:
15 01 00 00 00 00 02 36 10 or
and see what we get on display and if we can change the refresh direction. In worst case, we need to try all values from 00 for FF for the last byte in the command.
Anybody with a unlocked bootloader and time to recompile the kernel to test this ?
Click to expand...
Click to collapse
Interesting. I could only recommend you to try to get in touch with @flar2 - Dev of the EX kernel. He might be eventually able to do some experiments (as he already did with "inverted" command).
ddalex said:
Fair enough, I didn't check whenever this symbol is further referenced. Moreover, in MIPI DCS language, 'inverted' refers to 'color-inverted' display, not 'orientation-inverted'.
So I got curious, and took the DTSi file for the panel and the patch to enable the closely related S6E3FA0 panel on Exynos (never made it upstream), and decoded the `qcom,mdss-dsi-on-command` sequence, since it seems the best place to insert a command to rotate the display, if it exists; my decoding is below (references https://www.tonylabs.com/wp-content/uploads/MIPI_DCS_specification_v1.02.00.pdf)
Code:
.1 .2 .3 .4 .5 .6 .7 .8 .9 # decode of byte .8
#=============================================
05 01 00 00 14 00 02 11 00 # DCS exit_sleep_mode
15 01 00 00 00 00 02 35 00 # DCS set_tear_on
39 01 00 00 00 00 03 F0 5A 5A # MCS_KEY_LEV1
39 01 00 00 00 00 02 B0 04 # MCS_GLOBAL_PARAMETER
39 01 00 00 00 00 04 B4 06 0C 12 # ?? undocumented
39 01 00 00 00 00 03 F0 A5 A5 # MCS_KEY_LEV1
15 01 00 00 00 00 02 53 20 # ?? undocumented
15 01 00 00 00 00 02 55 00 # ?? DCS_WRITE_CABC
39 01 00 00 00 00 03 F0 5A 5A # MCS_KEY_LEV1
39 01 00 00 00 00 02 C3 01 # ?? undocumented
39 01 00 00 00 00 02 B0 18 # MCS_GLOBAL_PARAMETER
39 01 00 00 00 00 02 C3 00 # ?? undocumented
39 01 00 00 00 00 03 F0 A5 A5 # MCS_KEY_LEV1
05 01 00 00 00 00 02 29 00 # DCS set_display_on
In the MIPI DCS specification, one can control the Device Line Refresh Order:
Things I would try:
Find Samsung references for the display controller so we can find the undocumented commands below
Use command DCS set_address_mode 36h to flip the display: insert before the last line:
Code:
15 01 00 00 00 00 02 36 10
or
Code:
15 01 00 00 00 00 02 36 00
and see what we get on display and if we can change the refresh direction. In worst case, we need to try all values from 00 for FF for the last byte in the command.
Anybody with a unlocked bootloader and time to recompile the kernel to test this ?
Click to expand...
Click to collapse
This looks correct. I wondered about this but couldn't find a DCS spec sheet.
Could you specify what 15 01 does? Put the device into command mode or something?
Looking at the command documentation these bytes '#9' could be useful:
0x10 - scan from bottom to top (top to bottom in reality)
0x04 - latch from right to left (left to right in reality) (reverses tilt of the active scan line)
0x14 - combine previous 2
There are 2 problems that can come out of this:
1. The panel itself just doesn't support setting these bits and will just ignore them
2. "qcom,mdss-dsi-panel-orientation" might actually call that same command after qcom,mdss-dsi-on-command and override the settings we added in. This would show the same symptoms as problem 1), nothing would change in the display. I've been looking at the dsi panel init source code but it's a bit of a rabbit hole so I don't know if this is the case. Luckily the code is full of debug prints, so it is relatively easy to enable them and see what is actually happening in the dmesg.
who's gonna try this then ?
ZakooZ said:
This looks correct. I wondered about this but couldn't find a DCS spec sheet.
Could you specify what 15 01 does? Put the device into command mode or something?
Click to expand...
Click to collapse
Each line in there is a MIPI DCS packet - first byte is the packet type, with the defines below
Code:
/* dcs read/write */
#define DTYPE_DCS_WRITE 0x05 /* short write, 0 parameter */
#define DTYPE_DCS_WRITE1 0x15 /* short write, 1 parameter */
#define DTYPE_DCS_READ 0x06 /* read */
#define DTYPE_DCS_LWRITE 0x39 /* long write */
The complete header definition is:
Code:
struct dsi_ctrl_hdr {
char dtype; /* data type */
char last; /* last in chain */
char vc; /* virtual chan */
char ack; /* ask ACK from peripheral */
char wait; /* ms */
short dlen; /* 16 bits */
} __packed;
After the header, the payload follows directly.
ZakooZ said:
Looking at the command documentation these bytes '#9' could be useful:
0x10 - scan from bottom to top (top to bottom in reality)
0x04 - latch from right to left (left to right in reality) (reverses tilt of the active scan line)
0x14 - combine previous 2
Click to expand...
Click to collapse
Yep, we need to test these - the problem is that we don;t know if there is another piece of code that resets this flag after the initial init, you correctly touch on this below.
ZakooZ said:
There are 2 problems that can come out of this:
1. The panel itself just doesn't support setting these bits and will just ignore them
2. "qcom,mdss-dsi-panel-orientation" might actually call that same command after qcom,mdss-dsi-on-command and override the settings we added in. This would show the same symptoms as problem 1), nothing would change in the display. I've been looking at the dsi panel init source code but it's a bit of a rabbit hole so I don't know if this is the case. Luckily the code is full of debug prints, so it is relatively easy to enable them and see what is actually happening in the dmesg.
Click to expand...
Click to collapse
Or, possible but not probable outcome no. 3: the HUT (Hardware Under Test) is damaged by this testing
:victory:
That flag is shipped in this commit: https://github.com/MoKee/android_ke...mmit/7ca61f58d8b59a4ae716e08405df8368a45407fb
As I am a Chinese, this commit message indicates the screen is upside-down. This flag is not as others say, only see in Oneplus devices. It is a flag introduced by CAF, to support
upside-down screens: https://github.com/MoKee/android_ke...mmit/63203b502ef862f756535e080c4261031eb4110f. Further research shows that it actually does is to make the display oriented: https://github.com/MoKee/android_ke...f9e1a022ef5/include/uapi/linux/msm_mdp.h#L254.
Oneplus seems to take entire CAF solution in kernel. But actually it is something besides than kernel. But I doubt there is something in closed-source vendors as well (third-party roms still have this effect).
aviraxp said:
That flag is shipped in this commit: https://github.com/MoKee/android_ke...mmit/7ca61f58d8b59a4ae716e08405df8368a45407fb
As I am a Chinese, this commit message indicates the screen is upside-down. This flag is not as others say, only see in Oneplus devices. It is a flag introduced by CAF, to support
upside-down screens: https://github.com/MoKee/android_ke...mmit/63203b502ef862f756535e080c4261031eb4110f. Further research shows that it actually does is to make the display oriented: https://github.com/MoKee/android_ke...f9e1a022ef5/include/uapi/linux/msm_mdp.h#L254.
Oneplus seems to take entire CAF solution in kernel. But actually it is something besides than kernel. But I doubt there is something in closed-source vendors as well (third-party roms still have this effect).
Click to expand...
Click to collapse
Yes, but we don't need to reverse the screen, we need to set the inverse refresh.
Inviato dal mio ONEPLUS A5000 utilizzando Tapatalk
robertogl said:
Yes, but we don't need to reverse the screen, we need to set the inverse refresh.
Click to expand...
Click to collapse
I referenced above the Display Line Refresh Order option on the MIPI DCS standard set_address_mode option, that maybe could inverse the refresh. We need somebody to build the kernel with the command added in the DTSi file, and test it. Maybe @Sultanxda ?
Someone really should try this :0
Sent from my SM-A510M using Tapatalk