Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Yoshino, Tone(Maybe All)] Fake high screen frame rate(120Hz) #444

Open
sjllls opened this issue Jul 26, 2019 · 53 comments

Comments

@sjllls
Copy link

commented Jul 26, 2019

Platform: Yoshino, Tone(Maybe all)
Device: Maple, dora
Kernel version: 4.4, 4.9
Android version: 8.1, 9.0

Issues One
Dynamic resolution is broken in ExtendedSettings on Pie.

Issues Two
High screen frame rate is fake, system still renders UI at 60Hz. Maybe screen works at higher frame rate. But system only render 60 frames per second!

How to reproduce
Run Any SODP system, set it at higher screen frame rate. Check it with testufo or some games could display the frame rate, you will find system only run at 60Hz.

Note: Oneplus7 Pro could show 90Hz at Testufo.

How I verify
First: : I built a kernel at 100Hz, because Dynamic resolution is broken on Pie. After I tested, my Dora couldn't run at 120Hz.

Second: Check screen info with Dev Check(Or AID64)

Third: Check system render frame rate with Testufo. (Chrome and Firefox)

Fourth: Run some games which run over 60Hz.

Fifth: Repeat on Maple.

Some Pictures:
DSC_0027
DSC_0026
DSC_0025
DSC_0024

@sjllls

This comment has been minimized.

Copy link
Author

commented Jul 26, 2019

@sjllls sjllls changed the title [Yoshino, Tone] Fake high screen frame rate(120Hz) [Yoshino, Tone(Maybe All)] Fake high screen frame rate(120Hz) Jul 26, 2019
@lazerl0rd

This comment has been minimized.

Copy link

commented Jul 28, 2019

@sjllls it seems on SDE when you boot you get the high frame rate, if set correctly as default. But when the panel is turned off and on, it reverts to the original framerate as per the command on the CMD panel.

@sjllls

This comment has been minimized.

Copy link
Author

commented Jul 29, 2019

@sjllls it seems on SDE when you boot you get the high frame rate, if set correctly as default. But when the panel is turned off and on, it reverts to the original framerate as per the command on the CMD panel.

I found "CONFIG_DRM" is disabled for tone platform. It seems we still use old configurations. So even on first boot, the system is still working at 60Hz.
I refer to the kernel source of sharp shv34 and razer phone (Both of them are 120Hz).
Shv34 sets 120Hz in dtsi files. Razer phone uses dynamic resolution.
I try to compare the drivers in drivers/video. SODP is using their own drivers ported from stock. Shv34 and razer phone using the drivers of qcom.
But if you compare the stock panel drivers bewteen devices before Yoshino platform and those after Yoshino platform. You will find that the latter is more similar to shv34 and razer phone.

@lazerl0rd

This comment has been minimized.

Copy link

commented Jul 29, 2019

@sjllls it seems on SDE when you boot you get the high frame rate, if set correctly as default. But when the panel is turned off and on, it reverts to the original framerate as per the command on the CMD panel.

I found "CONFIG_DRM" is disabled for tone platform. It seems we still use old configurations. So even on first boot, the system is still working at 60Hz.
I refer to the kernel source of sharp shv34 and razer phone (Both of them are 120Hz).
Shv34 sets 120Hz in dtsi files. Razer phone uses dynamic resolution.
I try to compare the drivers in drivers/video. SODP is using their own drivers ported from stock. Shv34 and razer phone using the drivers of qcom.
But if you compare the stock panel drivers bewteen devices before Yoshino platform and those after Yoshino platform. You will find that the latter is more similar to shv34 and razer phone.

You stated yoshino in your issue, so I was referring to that.

Razer seems to us a "better" implementation of whatever we got here, but they may also use video panels instead of CMD panels.

@lazerl0rd

This comment has been minimized.

Copy link

commented Jul 29, 2019

Also, IIRC wasn't DynaFPS disabled in SODP recently?

@sjllls

This comment has been minimized.

Copy link
Author

commented Jul 29, 2019

@sjllls it seems on SDE when you boot you get the high frame rate, if set correctly as default. But when the panel is turned off and on, it reverts to the original framerate as per the command on the CMD panel.

I found "CONFIG_DRM" is disabled for tone platform. It seems we still use old configurations. So even on first boot, the system is still working at 60Hz.
I refer to the kernel source of sharp shv34 and razer phone (Both of them are 120Hz).
Shv34 sets 120Hz in dtsi files. Razer phone uses dynamic resolution.
I try to compare the drivers in drivers/video. SODP is using their own drivers ported from stock. Shv34 and razer phone using the drivers of qcom.
But if you compare the stock panel drivers bewteen devices before Yoshino platform and those after Yoshino platform. You will find that the latter is more similar to shv34 and razer phone.

You stated yoshino in your issue, so I was referring to that.

Razer seems to us a "better" implementation of whatever we got here, but they may also use video panels instead of CMD panels.

Yes, yoshino still uses legacy drivers in Oreo, so I mentioned it.
I had no idea about this issue, so I come here for help.
Do you get true 120Hz in your zfSODP ? I am busy with Lineage on maple these days, So I haven't tested it for 120Hz.

@lazerl0rd

This comment has been minimized.

Copy link

commented Jul 29, 2019

I get true 120FPS (now I switched to 90FPS) until my screen goes off and on @sjllls.

@sjllls

This comment has been minimized.

Copy link
Author

commented Jul 29, 2019

I get true 120FPS (now I switched to 90FPS) until my screen goes off and on @sjllls.

Nice, we may find the reason and solve it. :P

@sjllls

This comment has been minimized.

Copy link
Author

commented Aug 5, 2019

@lazerl0rd Hi, do you know waht's this meanning?
Link
----------------EDIT------------------------------
Maple
Poplar
Lilac

Does this means 60Hz on yoshino platform?

@lazerl0rd

This comment has been minimized.

Copy link

commented Aug 6, 2019

Idk how it works @sjllls, I think you need a QCOM BSP (confidential) or Angelo's reverse engineering magic. SODP worked around it by having dyna. FPS stuff.

39		01		00		00		00		00		03		44		00		00		(hex)

57		01		00		00		00		00		03		68		00		00		(decimal)

0011 1001	0000 0001	0000 0000	0000 0000	0000 0000	0000 0000	0000 0011	0100 0100	0000 0000	0000 0000	(binary)
@lss4

This comment has been minimized.

Copy link

commented Aug 6, 2019

This relatively old document might be useful (googling about this file returns multiple results from different trees, may need to find which one is the most recent).

Excerpt:

qcom,mdss-dsi-on-command:
A byte stream formed by multiple dcs packets base on qcom dsi controller protocol.
byte 0: dcs data type
byte 1: set to indicate this is an individual packet (no chain)
byte 2: virtual channel number
byte 3: expect ack from client (dcs read command)
byte 4: wait number of specified ms after dcs command transmitted
byte 5, 6: 16 bits length in network byte order
byte 7 and beyond: number byte of payload

So the line you highlighted (39 01 00 00 00 00 03 44 00 00) can be explained as much as:

byte 0: DCS data type 39h (0x39).
byte 1: Is individual packet (0x01).
byte 2: Virtual channel number 0 (0x00).
byte 3: Do not expect ack from client (0x00).
byte 4: Wait 0 ms after dcs command transmit (0x00).
byte 5,6: Length=3 (In network byte order / big endian: 0x00 0x03).
byte 7,8,9: Payload (0x44, 0x00, 0x00).

From the dtsi there are three packets related to frame-rate. The payload needs to be figured out in order to know how it's configured. More documentation is needed. Anyway, what's the exact model of XZ Premium's panel, and is there any datasheet for it?

EDIT: I found a datasheet for model LS055D1SX04 (which seems to be a close match) and could confirm most of the power-on commands from it. However, the lines in question regarding frame rate couldn't be found, except the line for enabling Tearing Effect (TE signal).

Guess we need to further look for the datasheet of its underlying controller, Novatek NT35950. However, I'm yet to find one.

EDIT 2: Just found a similar driver chip (NT35590) which appears to use a similar protocol. From the looks of it, the line you highlighted is a follow up of the line above (0x3500, SET_TEAR_ON). The command (0x4400) means SET_TEAR_SCANLINE. I'm not certain about how this affects frame rate.

EDIT 3: I think the actual frame rate configuration lies on the first line: BD 00 AC 0C 0C 00 01 56 09 09 01 01 0C 0C 00 D9. Unfortunately, the command (BD00) used here is not mentioned in any of the datasheets I found.

However, the BD command is briefly mentioned in the datasheet of a similar AUO panel (driven by the same driver IC). It has mentions about how to set 60Hz or 47.5Hz on that particular panel, but offered no explanation about the meaning of each parameter.

@sjllls

This comment has been minimized.

Copy link
Author

commented Aug 6, 2019

@lazerl0rd @lss4 The dtsi file of panel could be created by this tool of qcom.
The dtsi file could be generated by an xml file.

@lss4

This comment has been minimized.

Copy link

commented Aug 6, 2019

Unfortunately I can only go this far. I cannot find any more useful information regarding this particular command (BD00). The driver chip in question (NT35950) has no publicly known documents we can refer to.

Besides, after looking at the code a bit more, it seems the line in question is only present in the 1080p section. In the 4K section the line is absent. Could it be that particular command is not mandatory, or that the panel does not need to be configured if operating at 4K?

@sjllls

This comment has been minimized.

Copy link
Author

commented Aug 6, 2019

Unfortunately I can only go this far. I cannot find any more useful information regarding this particular command (BD00). The driver chip in question (NT35950) has no publicly known documents we can refer to.

Besides, after looking at the code a bit more, it seems the line in question is only present in the 1080p section. In the 4K section the line is absent. Could it be that particular command is not mandatory, or that the panel does not need to be configured if operating at 4K?

Thanks a lot, In fact, we can ask the menber of SODP team for help.

@lazerl0rd

This comment has been minimized.

Copy link

commented Aug 6, 2019

@lss4 reading more into https://ds0.me/H546UAN01.0.pdf, it seems that secondary rates may not need this line? The dynamic FPS initialization of it may not need it for "other frame rates" (see "47.4Hz setting (for reference)" and "Command Mode 60Hz Normal mode(OTP value),Dynamic frame 47.5Hz".

@sjllls

This comment has been minimized.

Copy link
Author

commented Aug 6, 2019

Unfortunately I can only go this far. I cannot find any more useful information regarding this particular command (BD00). The driver chip in question (NT35950) has no publicly known documents we can refer to.

Besides, after looking at the code a bit more, it seems the line in question is only present in the 1080p section. In the 4K section the line is absent. Could it be that particular command is not mandatory, or that the panel does not need to be configured if operating at 4K?

If you want to enable 4K. You could use these commands:

adb shell
su
setprop debug.sf.nobootanimation 1
setprop ctl.stop surfaceflinger
echo "U:2160x3840p-60" > /sys/devices/virtual/graphics/fb0/mode
setprop ctl.start surfaceflinger

You will see the image only in the upper left corner (1/4). The system still rendering at 1080x1920.
It seems to be a virtual device. Like Nvidia Dynamic Super Resolution (DSR) .

Besides. I had another question. Do the qcom,mdss-dsi-panel-clockrate related with panel framerate? I noticed in sde panel dtsi file, this parameter has changed. legacy SDE

We could compare with Razer phone, but our panel only have command-mode configuration. command video
Razer phone's qcom,dynamic-mode-switch-type is dynamic-switch-immediate. Ours is dynamic-resolution-switch-immediate.
According to the document from google. It seems dynamic-resolution-switch-immediate is used for switch resolution, like from 1080p to 4k.

SODP(SOMC) uses its own driver to change fps.

@lss4

This comment has been minimized.

Copy link

commented Aug 6, 2019

I tried removing the line in the 1080p section and built with 120Hz again and it's still operating at 24 fps. Guess that's probably not the right direction, either.

Plus, the line in question also appeared in here (in two places). Maybe I should try removing that part if those commands might also be invoked by the driver. If it's still not working after that then we'll need to look at another direction...

The BD command (as well as the BE command mentioned in that AUO panel's datasheet) remains a mystery as no known datasheets have explanations about them (even among similar Novatek driver chips).

Except a few bytes that seemed identical between ours and the AUO panel's, most of the values differ vastly that I can't really figure out anything that might indicate "configuring the panel to render at a particular frame rate". I suspect it might be panel-specific.

EDIT: Removing the part in somc,change-fps-command resulted in a bootloop at sony logo (may or may not be related). Guess that line is also executed by the SOMC driver. We need to look at the Sony driver code a bit more...

@lazerl0rd

This comment has been minimized.

Copy link

commented Aug 6, 2019

Well, IIRC it used to work on SODP a while back. And it does give me the correct framerate I want on-boot. Just switching the screen off and on resets to 60Hz.

@lss4

This comment has been minimized.

Copy link

commented Aug 6, 2019

The SOMC driver seems to write to this attribute (somc,driver-ic-total-porch) somewhere given our panel type (uhd_4k_type).

I attempted to change this value (as well as qcom,mdss-dsi-v-front-porch and qcom,mdss-dsi-v-back-porch) to something else and I got stuck at Sony logo (it's not even rebooting). I'm afraid we'll need to dig in deeper to figure out what really controls the frame rate.

@sjllls

This comment has been minimized.

Copy link
Author

commented Aug 7, 2019

@lss4 @lazerl0rd Our panel seems could only initialize on 1080p-0~144Hz, if your use 4K or higher than 144Hz on 1080p, you will stuck at Sony logo. (System runs fine).
Here is a log from Los16.

08-07 07:59:40.682  1445  1495 I DisplayManagerService: Display device added: DisplayDeviceInfo{"Built-in screen": uniqueId="local:0", 1080 x 1920, modeId 2, defaultModeId 2, supportedModes [{id=1, width=2160, height=3840, fps=90.0}, {id=2, width=1080, height=1920, fps=90.0}], colorMode 0, supportedColorModes [0], HdrCapabilities android.view.Display$HdrCapabilities@bbb6a935, density 420, 403.411 x 403.041 dpi, appVsyncOff 2000000, presDeadline 6111111, touch INTERNAL, rotation 0, type BUILT_IN, state UNKNOWN, FLAG_DEFAULT_DISPLAY, FLAG_ROTATES_WITH_CONTENT, FLAG_SECURE, FLAG_SUPPORTS_PROTECTED_BUFFERS}
08-07 07:59:40.683  1445  1445 I SystemServer: StartPackageManagerService
08-07 07:59:40.683  1445  1495 I DisplayManagerService: Display device changed state: "Built-in screen", ON

The log show the panel support 4K-90Hz, in fact, I only modified the framerate of 1080p.

@lss4

This comment has been minimized.

Copy link

commented Aug 7, 2019

@lss4 @lazerl0rd Our panel seems could only initialize on 1080p-0~144Hz, if your use 4K or higher than 144Hz on 1080p, you will stuck at Sony logo. (System runs fine).
Here is a log from Los16.

08-07 07:59:40.682  1445  1495 I DisplayManagerService: Display device added: DisplayDeviceInfo{"Built-in screen": uniqueId="local:0", 1080 x 1920, modeId 2, defaultModeId 2, supportedModes [{id=1, width=2160, height=3840, fps=90.0}, {id=2, width=1080, height=1920, fps=90.0}], colorMode 0, supportedColorModes [0], HdrCapabilities android.view.Display$HdrCapabilities@bbb6a935, density 420, 403.411 x 403.041 dpi, appVsyncOff 2000000, presDeadline 6111111, touch INTERNAL, rotation 0, type BUILT_IN, state UNKNOWN, FLAG_DEFAULT_DISPLAY, FLAG_ROTATES_WITH_CONTENT, FLAG_SECURE, FLAG_SUPPORTS_PROTECTED_BUFFERS}
08-07 07:59:40.683  1445  1445 I SystemServer: StartPackageManagerService
08-07 07:59:40.683  1445  1495 I DisplayManagerService: Display device changed state: "Built-in screen", ON

Okay... but apparently I didn't change anything other than the porch values. Guess changing it to a wrong value can also trigger that.

The thing is how we're going to initialize the panel to work at 90 FPS.

Removing the BD command from both the qcom,mdss-dsi-on-command and somc,change-fps-command would result in a bootloop at Sony logo, while removing the command only from the qcom,mdss-dsi-on-command has no apparent effect. It's possible that Sony's driver also invokes the command at some point (so the command in qcom,mdss-dsi-on-command can be optional, as the line is absent in the 4K section, while the rest are identical to 1080p). If that can be proven true, it might explain why the panel reverts to 60FPS after a power cycle.

Or we can try fiddling with the values (consisting of 15 bytes) presented to that command to see if we really can alter the actual frame rate that way.

@sjllls

This comment has been minimized.

Copy link
Author

commented Aug 7, 2019

@kholk Hi, could you do us a favor? Thanks !

@lazerl0rd

This comment has been minimized.

Copy link

commented Aug 7, 2019

He's on holiday now @sjllls , IIRC.

@lss4

This comment has been minimized.

Copy link

commented Aug 8, 2019

By the way, daveshah1 (who is also the one hosted the datasheets of the panels on his site, that came up in the search results when I was googling) once posted some info (extracted from stock firmware at that time) and analysis regarding our panel on XDA here. According to his thread the panel's similar to that of the Z5 Premium (satsuki), with the same driver chip.

And it seems from the extracted information, the BD command line in the somc,change-fps-command was a bit different and was formatted in this manner:

0x390100 0x10 0xbd00ac0c 0xc000159 0x909010e 0xc0c00b4

Taking out the bytes that actually matter, we have this:

00 ac 0c 0c 00 01 59 09 09 01 0e 0c 0c 00 b4

These parameters are slightly different than the ones we are using in the kernel... Not much a clue, but it might worth starting from there. Maybe we can also refer to satsuki's kernel trees (if any) to see if we can find anything interesting.

EDIT: The usefulness of those panels' documentation depends on whether those panels really supports 90/120 FPS or not. For now it seems the datasheets of the panels we're referring to didn't really mention anything about 120Hz, only 60Hz.

@sjllls

This comment has been minimized.

Copy link
Author

commented Aug 8, 2019

satsuk

The panel tree of Z5P. And it own the same fps-change command as XZP.
We need to find the reason resets the frame rate on SDE driver and why can't we get true 120Hz on msmfb(legacy) driver.
@lazerl0rd said he already got 120Hz on SDE driver. So I don't need to worry about whether our panel could support 120Hz. I also enabled full 4K resolution on Los. So I think the bandwidth of our panel could afford 4k-60Hz and 1080p-240Hz.
-----------EDIT----------
There is another possibility here. The IC of our panel could deal with the input at 1080p-120Hz, but the screen could only work at 60Hz.
Screen frame rate, system rendering fps, touch refresh rate, they may work at different status.
It's a little difficult for me to read and understand the somc panel drivers fully.

@lazerl0rd

This comment has been minimized.

Copy link

commented Aug 9, 2019

There's VSync too, don't forget that. But it seems fine for me on SDE.

@lss4

This comment has been minimized.

Copy link

commented Aug 16, 2019

I found this comment in ZfSODP thread:

The 90hz display is laggy af for me. Seems worse than 60hz and keeps scrambling the display randomly. If someone knows how I can change it back to 60hz via termux or adb, please let me know.

And this comment:

  1. 90Hz is rly smooth, but launcher apps are felling kinda laggy - setting my live wallpaper on forced 35fps fixed this strange issue

Not sure what these exactly mean, but is 90Hz/120Hz running stable on ZfSODP at the moment? Or could those comments be also related to the issue you're facing (Running at 90Hz/120Hz at boot but reverts to 60Hz after power cycling the panel)? By the way, does ZfSODP use the SDE driver?

I think I'll need to take a look at respective sections on enabling 90Hz/120Hz on SDE drivers to see if there might something that might equate to the commands sent by SOMC's driver to the panel. For now I don't think I could find anything new from SOMC's driver alone.

@sjllls

This comment has been minimized.

Copy link
Author

commented Aug 16, 2019

Not sure what these exactly mean, but is 90Hz/120Hz running stable on ZfSODP at the moment? Or could those comments be also related to the issue you're facing (Running at 90Hz/120Hz at boot but reverts to 60Hz after power cycling the panel)? By the way, does ZfSODP use the SDE driver?

I think I'll need to take a look at respective sections on enabling 90Hz/120Hz on SDE drivers to see if there might something that might equate to the commands sent by SOMC's driver to the panel. For now I don't think I could find anything new from SOMC's driver alone.

There also are some strange problems on Treble for maple, too.
Some users feedback to me that they will meet black screen after waking up screen. Some users feedback to me that the half of the screen is full of colour blocks. Other feedback to me the all are fine.
But they use the same GSI.

@sjllls

This comment has been minimized.

Copy link
Author

commented Aug 18, 2019

@lss4 @lazerl0rd Oneplus 7 Pro is the same as our devices. It only has command mode for the panel.
Here is the panel dtsi file, hope it is useful.

@lazerl0rd

This comment has been minimized.

Copy link

commented Aug 18, 2019

The thing is we had/have a working SOMC FPS switcher, so I just need someone to explain how to set that up again (since it was enabled a while back).

@lazerl0rd

This comment has been minimized.

Copy link

commented Aug 18, 2019

Or for someone to tell me it’s broken on SDE.

@MartinX3

This comment has been minimized.

Copy link

commented Aug 18, 2019

Maybe useful to read
#94

@lss4

This comment has been minimized.

Copy link

commented Aug 18, 2019

I've got some time fiddling with the command values and found something that might be useful:
In somc,change-fps-command:
BD 00 AC 0C 0C 00 01 59 09 09 01 0E 0C 0C 00 B4
In qcom,mdss-dsi-on-command:
BD 00 AC 0C 0C 00 01 56 09 09 01 01 0C 0C 00 D9
Notice the 3rd byte (ACh) and the last byte (B4/D9).

Comparing to the reference value in the AUO panel's document:
BD 00 AA 12 24 00 01 56 00 00 01 42 00 00 00 D7 for 60Hz (Dynamic 47.5Hz)
BD 00 D7 12 24 00 01 AE 00 00 01 42 00 00 00 D7 for 47.5Hz

It seems the values passed to the 3rd byte and last byte are probably for dividers that are tied to the intended frame rate as if you multiply the bytes with their corresponding vertical refresh rate you get a similar value (which is probably the rate of the clock signal that's being sent to the panel or the driver IC).
170(AAh) * 60 = 10200
215(D7h) * 47.5 = 10212.5

Now look at our panel:
172(ACh) * 60 = 10320
10320 / 217(D9h) = 47.5576036866 (around 47.5 Hz)
10320 / 180(B4h) = 57.3333333333 (Not sure why somc,change-fps-command would use this)

This is not everything, but it gives a strong indication that our panel is also using 60Hz normal frame rate with a dynamic frame rate of 47.5Hz just like the AUO panel.

While I'm still getting 60Hz at the moment (even after replacing those values to 56h which should correspond to 120Hz), it doesn't appear I can put any values I wanted. So far fiddling the command parameters had no apparent effect (it still operates at 60Hz).

At one time I attempted to use 6Ch for the last byte (which equates to 95Hz, in the same proportion as 60Hz/47.5Hz, for 120Hz/95Hz), and I got myself a screen that's stuck on sony logo (but the system is booting underneath).

Setting refresh rate to some different ones (70Hz, 75Hz, etc.) resulted in glitched video output that's not usable.

I'm still planning to fiddle the commands a bit further. While I still can't get values above 60 fps, I managed to get a 56 fps using at least the following commands (actually the 72h here should correspond to 90Hz, which is also the framerate, and I'm yet to figure out what the 8th byte really means):

BD 00 72 0C 0C 00 01 72 09 09 01 01 0C 0C 00 72
BE 00 72 0C 0C 00 01 72 09 09 01 01

(The BE command is a mimic to the AUO panel's, and may not have any apparent effect).

As for the dtsi file you just referenced... does Oneplus 7 Pro also use the same Novatek controller underneath (NT35950)? Plus, does it also use a kernel driver similar to ours? The panel's power on commands look rather different.

EDIT: The 8th byte (which was originally 56h) seemed to play a more significant role in the frame rate. Setting this to 68h (while setting the 3rd and last byte to 78h, though it may not entirely matter as I set several different values and had no effect) got me a 58 fps. I then decided to set this to 16h while setting the others to 56h, got a glitched display... will continue fiddling the 8th byte and see what else I could get...

EDIT 2: Adding 10h to the 8th byte lowers the frame rate by 2 fps (from the looks of it, increasing this byte further, like with AUO's example (AEh), would result in a frame rate closer to 47.5 fps), but it appears I cannot subtract any further from 56h (which gives me 60 fps) as the screen would end up glitched. It seems with the current driver I simply just can't attempt to bring the frame rate higher than 60 fps, without altering any code.

EDIT 3: Yep... I really can't subtract any further. Setting to 55h (or 54h) would result in some white lines showing on the screen but barely readable (although I get 61 FPS under this condition).

The information regarding the parameters is still limited... not sure if it's possible to alter the panel/driver's clock input.

I'm calling it a day. I've made (and flashed) twenty builds just to fiddle the dsi panel values... with only a few useful discoveries.

@sjllls

This comment has been minimized.

Copy link
Author

commented Aug 18, 2019

As for the dtsi file you just referenced... does Oneplus 7 Pro also use the same Novatek controller underneath (NT35950)? Plus, does it also use a kernel driver similar to ours? The panel's power on commands look rather different.

Both oneplus 7 pro and maple are only using command mode. There are 60&90 Hz's configurations in oneplus 7's dtsi file. We can compare the difference of them.
Diff1 Diff2 Diff3
But our panel seems use a different way to change-fps in somc drivers.

@lazerl0rd

This comment has been minimized.

Copy link

commented Aug 18, 2019

@lss4 on ZfSODP I got 90Hz working until screen goes off. It’s defo working like that. I believe 120Hz has the same “issue”.

I think the SOMC change FPS command needs to be “triggered” in some way. There are other 120Hz panels and stock we can look at in this situation.

I am trying the following to resolve my issue:
ZfSODP/kernel_sony_msm-4.9_kernel@0ded611
and
ZfSODP/kernel_sony_msm-4.9_kernel@8bb8b82 as the OnePlus 7 Pro’s panel dt.

@sjllls is correct in that we are using SOMC Dynamic FPS switcher and they seem to do something else.

EDIT: Ye, I noticed after the commit I needed to change the length - but ended up not helping.

@lazerl0rd

This comment has been minimized.

Copy link

commented Aug 18, 2019

It’s possible that DRS (including SOMC Dynamic FPS Switcher) isn’t ready in DRM/SDE.

@sjllls

This comment has been minimized.

Copy link
Author

commented Aug 18, 2019

It’s possible that DRS (including SOMC Dynamic FPS Switcher) isn’t ready in DRM/SDE.

I think it's also broken with msmfb drivers. I tested on omnirom 8.1 with a 90Hz kernel. It also shows 60fps in testufo. We need to know the definitions of these commands in our dtsi files.
--------EDIT------------
I also think the reset of framerate is related with the black screen issue on SDE.

@lazerl0rd

This comment has been minimized.

Copy link

commented Aug 18, 2019

You mean MDSS @sjllls? DRS 4K and 120Hz was working for me in October last year (when FBDEV/MDSS was being used instead of DRM/SDE).

I doubt your second point tho, I think the screen crash is just a problem with SDE, looking at the logs and such.

@lss4

This comment has been minimized.

Copy link

commented Aug 18, 2019

It’s possible that DRS (including SOMC Dynamic FPS Switcher) isn’t ready in DRM/SDE.

I think it's also broken with msmfb drivers. I tested on omnirom 8.1 with a 90Hz kernel. It also shows 60fps in testufo. We need to know the definitions of these commands in our dtsi files.
--------EDIT------------
I also think the reset of framerate is related with the black screen issue on SDE.

Is the msmfb driver what the stock-based kernel uses?

From what I've experimented so far, I don't think a frame rate higher than 60 fps can be reliably obtained with the driver. However, one can obtain a lower frame rate if wanted, by changing the value of the 8th byte (which was originally 56h) to something higher (this partially matches how to configure the reference AUO panel to 47.5Hz).

@lss4 on ZfSODP I got 90Hz working until screen goes off. It’s defo working like that. I believe 120Hz has the same “issue”.

I think the SOMC change FPS command needs to be “triggered” in some way. There are other 120Hz panels and stock we can look at in this situation.

I am trying the following to resolve my issue:
ZfSODP/kernel_sony_msm-4.9_kernel@0ded611
and
ZfSODP/kernel_sony_msm-4.9_kernel@8bb8b82 as the OnePlus 7 Pro’s panel dt.

@sjllls is correct in that we are using SOMC Dynamic FPS switcher and they seem to do something else.

By the way...

39 01 00 00 00 00 (10) BD 00
You simply removed some bytes from the command without changing the data length (the byte in the bracket). This can lead to some unexpected effects. You may try this:
39 01 00 00 00 00 02 BD 00
Although I don't think it's going to work either, as the command (BD) expects 15 bytes following it, making it 16 bytes (10h) in total.

Also, in a previous experiment, it seems somc,change-fps-command (which also contained the BD command) has a higher priority, and qcom,mdss-dsi-on-command doesn't always need to contain that part (the command in question is absent in 4K settings). However, if the BD command is also absent in somc,change-fps-command, I get a screen that looked like the phone is being stuck at sony logo, but the system is actually working underneath. That kinds of implied the command is indeed needed to initialize the panel (and that the somc,change-fps-command is indeed called at some point).

@lazerl0rd

This comment has been minimized.

Copy link

commented Aug 18, 2019

@lss4 yeah that idea didn’t work out, and didn’t even boot. I tried adding the 1080p90 configs to the FBDEV/MDSS dts too then 90Hz didn’t even work on boot anymore. Weird.

@lss4

This comment has been minimized.

Copy link

commented Aug 19, 2019

You mean MDSS @sjllls? DRS 4K and 120Hz was working for me in October last year (when FBDEV/MDSS was being used instead of DRM/SDE).

I doubt your second point tho, I think the screen crash is just a problem with SDE, looking at the logs and such.

Can you confirm whether it was real 120Hz back then?

From what I've tested yesterday it doesn't seem that simple to attain real 90Hz (not to mention 120Hz). We might need to alter some other parameters (like input clock and such).

I've already found the byte in the BD command that could actually adjust the frame rate. However, setting to anything that leads to a frame rate higher than 60 fps (reducing it from 56h/59h) would result in issues. Reducing it by 1-2 would give me 61 fps with some white lines appearing on the panel (but still barely usable). Reducing it even more would result in a totally garbled display. Increasing this value would give you a lower frame rate than 60 fps and without graphical problems. I suspect that byte is probably used for some kind of fine-tuning.

Not sure what those 0C 0C and 09 09 bytes do, but the example in the AUO panel used something rather different (12 24 and 00 00). Given that no explanations regarding the BD command is available, experiments are needed to figure out what those values really do.

As for OnePlus 7 Pro... if its panel is not using the same or similar Novatek controller, its usefulness as a reference would be limited, as some of the commands appear to be controller-specific (despite they all follow the dsi protocol). Oneplus 7 Pro's panel is from Samsung, and I can't find any information regarding it or its controller yet.

@sjllls

This comment has been minimized.

Copy link
Author

commented Aug 19, 2019

You mean MDSS @sjllls? DRS 4K and 120Hz was working for me in October last year (when FBDEV/MDSS was being used instead of DRM/SDE).

I doubt your second point tho, I think the screen crash is just a problem with SDE, looking at the logs and such.

@lazerl0rd Yes, I mean the old display drivers.
Can you confirm it is true 120Hz? I tested on SODP-8.1 last month. The DSR is not broken, but it can't adjust the framerate. I tested on Testufo, it still shows 60fps.So it's fake 120Hz.

@lss4 Comparing with Oneplus 7 Pro. If you tweaked the framerate in BD command. You may also need a different mdss-dsi-panel-phy-timings to support the new framerate. Command panel has their default timing settings to support default framerate. I think this is why you stuck at sony logo.

----------------EDIT---------------------
According to other phones' developers, the panel working at video mode could get higher framerate by modifying qcom,mdss-dsi-panel-clockrate and qcom,mdss-dsi-panel-framerate. LIke Redmi K20 Pro, Xiaomi 9.
But for the ones working at command mode, framerate is not only controled by the two parameters. Like Oneplus 6, Oneplus 7 Pro.

@lss4

This comment has been minimized.

Copy link

commented Aug 19, 2019

@lss4 Comparing with Oneplus 7 Pro. If you tweaked the framerate in BD command. You may also need a different mdss-dsi-panel-phy-timings to support the new framerate. Command panel has their default timing settings to support default framerate. I think this is why you stuck at sony logo.

I looked at the Oneplus 7 Pro's files.
Its panel doesn't appear to be using the same controller as ours. Also, our PHY timing array has 12 bytes while Oneplus 7 Pro has 14 bytes.

While I'm searching for guides regarding PHY timings I came across this. I think I'll give this a try (if I have the correct specifications of our panel). Although I'm not sure if this spreadsheet applies to MSM8998 (SD835).

EDIT: Nope... it's probably not what I really needed. The values it calculated are way too different from the values in the dtsi file that I can't really refer to... (EDIT 2: It seems the PHY 2.0 part contains stuffs that looked closer to the ones I wanted)

@lazerl0rd

This comment has been minimized.

Copy link

commented Aug 19, 2019

You mean MDSS @sjllls? DRS 4K and 120Hz was working for me in October last year (when FBDEV/MDSS was being used instead of DRM/SDE).
I doubt your second point tho, I think the screen crash is just a problem with SDE, looking at the logs and such.

Can you confirm whether it was real 120Hz back then?

From what I've tested yesterday it doesn't seem that simple to attain real 90Hz (not to mention 120Hz). We might need to alter some other parameters (like input clock and such).

I've already found the byte in the BD command that could actually adjust the frame rate. However, setting to anything that leads to a frame rate higher than 60 fps (reducing it from 56h/59h) would result in issues. Reducing it by 1-2 would give me 61 fps with some white lines appearing on the panel (but still barely usable). Reducing it even more would result in a totally garbled display. Increasing this value would give you a lower frame rate than 60 fps and without graphical problems. I suspect that byte is probably used for some kind of fine-tuning.

Not sure what those 0C 0C and 09 09 bytes do, but the example in the AUO panel used something rather different (12 24 and 00 00). Given that no explanations regarding the BD command is available, experiments are needed to figure out what those values really do.

As for OnePlus 7 Pro... if its panel is not using the same or similar Novatek controller, its usefulness as a reference would be limited, as some of the commands appear to be controller-specific (despite they all follow the dsi protocol). Oneplus 7 Pro's panel is from Samsung, and I can't find any information regarding it or its controller yet.

I used two FPS apps to test, and I compared to higher than 60Hz refresh rates on other devices. It did work.

@lazerl0rd

This comment has been minimized.

Copy link

commented Aug 19, 2019

@sjllls our clock rate is high enough. If it can handle 4k60, it can handle 1080p90.

@lazerl0rd

This comment has been minimized.

Copy link

commented Aug 19, 2019

You mean MDSS @sjllls? DRS 4K and 120Hz was working for me in October last year (when FBDEV/MDSS was being used instead of DRM/SDE).
I doubt your second point tho, I think the screen crash is just a problem with SDE, looking at the logs and such.

@lazerl0rd Yes, I mean the old display drivers.
Can you confirm it is true 120Hz? I tested on SODP-8.1 last month. The DSR is not broken, but it can't adjust the framerate. I tested on Testufo, it still shows 60fps.So it's fake 120Hz.

@lss4 Comparing with Oneplus 7 Pro. If you tweaked the framerate in BD command. You may also need a different mdss-dsi-panel-phy-timings to support the new framerate. Command panel has their default timing settings to support default framerate. I think this is why you stuck at sony logo.

----------------EDIT---------------------
According to other phones' developers, the panel working at video mode could get higher framerate by modifying qcom,mdss-dsi-panel-clockrate and qcom,mdss-dsi-panel-framerate. LIke Redmi K20 Pro, Xiaomi 9.
But for the ones working at command mode, framerate is not only controled by the two parameters. Like Oneplus 6, Oneplus 7 Pro.

Ah, so in old SODP it didn't actually work. IIRC I did somehow get it working back then as I showed my friend a screenshot of an FPS app with 120FPS being rendered and displayed. The UI was also pretty smooth. There was like a billion FCs at that point tho, so I reverted to stock.

@lss4

This comment has been minimized.

Copy link

commented Aug 19, 2019

Ah, so in old SODP it didn't actually work. IIRC I did somehow get it working back then as I showed my friend a screenshot of an FPS app with 120FPS being rendered and displayed. The UI was also pretty smooth. There was like a billion FCs at that point tho, so I reverted to stock.

Did you also test whether the refresh rate would be reverted upon power cycle at that time?

If that wasn't the case... maybe we can look at the particular commits that made it work back then. Those commits might be helpful for figuring out why it's not working correctly right now.

@lazerl0rd

This comment has been minimized.

@lss4

This comment has been minimized.

Copy link

commented Aug 20, 2019

@lss4 @sjllls not sure if this is useful but... https://gitlab.com/ZKP/yoshino/blob/latest/arch/arm/boot/dts/qcom/dsi-panel-sharp-dualmipi-1080p-120hz.dtsi.

Good find. I think we might be able to use the timings in that file as a reference.
However, the exact name of the panel you referenced is still not known, and might be using a different controller, as its commands use almost exclusively the 15h data type (DCS Short Write, 1 parameter), with only one command using 39h (DCS Long Write).

EDIT: This extracted DTS by daveshah1 might also be useful.

@lazerl0rd

This comment has been minimized.

Copy link

commented Aug 20, 2019

@sjllls

This comment has been minimized.

Copy link
Author

commented Aug 20, 2019

A really badly commit-named repo with somethings I'm trying - https://github.com/ZfSODP/kernel_sony_msm-4.9_kernel/commits/1df2ee0045704d2ef3ce0b68b63401236f09115d.

The qcom,mdss-dsi-max-refresh-rate is not in msm8996-mdss-panels.dtsi, but 120Hz is not working on tone platform, either.
And I don't know why do they include so many dtsi files (seems not related with our panel) in this dtsi file.

@lss4

This comment has been minimized.

Copy link

commented Aug 21, 2019

A really badly commit-named repo with somethings I'm trying - https://github.com/ZfSODP/kernel_sony_msm-4.9_kernel/commits/1df2ee0045704d2ef3ce0b68b63401236f09115d.

The qcom,mdss-dsi-max-refresh-rate is not in msm8996-mdss-panels.dtsi, but 120Hz is not working on tone platform, either.
And I don't know why do they include so many dtsi files (seems not related with our panel) in this dtsi file.

Apparently the maple dtsi we use on the stock-based tree contained three sections. The first is about ID3 (Satsuki/Z5P), the second is about ID6 (Maple/XZP, which is our device) and a third "default" section that doesn't contain somc,change-fps-command.

Another possibility for including many seemingly unrelated panel's definitions, I think, would be to make life easier for aftermarket repair shops in case someone broke the phone's panel and they either cannot find an identical replacement part, or an identical replacement part cannot be used due to budget constraints (usually when the user is considering getting a new phone in the near future, and would not bother spending too much to keep the old damaged device usable until then).

@lazerl0rd have you tested these additions on ZfSODP? If the results are promising, I'd like to try this on stock-based trees as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.