eDP flat panel not working

[korli]

Laptop ASUS Zenbook UX31E-RY029V, integrated panel.

hrev53878 dirty

[korli]

syslog ASUS Zenbook UX31E-RY029V

[pulkomandy]

What is the last known working revision?

[pulkomandy]

According to the syslog it uses embedded DisplayPort, which is not supported by the driver (it won't even try to set a videomode)

[korli]

Can't remember whether it ever worked, sorry. I could check with beta1 and alpha4.

[pulkomandy]

I'm mostly interested to know if it's a regression from the last few month changes. If its not, I'd say it can wait a bit more and we can look into it later (I'd rather get the VGA output working completely first. And I need to get a DisplayPort cable and display to test that on my laptop...)

[korli]

The screen now turns white after the boot screen. it looks like #17350 The app_server tries to set the correct native resolution 1600x900.

[korli]

syslog hrev55674

[korli]

syslog hrev55688

[korli]

intel_reg dump

[korli]

Same behavior here too (note I had to boot on a USB2 port as USB3 boot seems now broken).

[waddlesplash]

(note I had to boot on a USB2 port as USB3 boot seems now broken).

This deserves its own ticket. Any change you can collect information? (Is it a regression or did it never work on this hardware?)

[rudolfc]

Hi, I am currently working on this.. Would be nice if a new syslog could be uploaded since I put some time in yesterday, and will do so the coming time as well.. I mean the white panel ;-)

[korli]

custom build

[korli]

Hi, here is an updated short syslog for intel_extreme. the white panel is still with us :)

[rudolfc]

Thank you, Looks indeed the same as #17350 so far. Keep the ticket open however just to be sure. Since you filtered the syslog I am missing the actual VESA info dumped by the driver to the log, could you add that for completeness sake?

I'll modify the driver more for a new test with the panel, same as that other ticket. Thanks again!

[rudolfc]

Hi, just committed hrev55845, which has a good chance to improve your situation. Please test it and upload the syslog once more, with VESA dump, and with your comments :-)

Thanks a lot!

[korli]

syslog hrev55845

[korli]

Hi, just tested with hrev55845. The display shows vertical lines, then ends up white.

[rudolfc]

Hi, progress :-)

Do you mind changing one line in the source, recompile and quickly test? I was assuming the panel uses two lanes, but seems it's four even.

In the log you see this message: SetFDILink: FDI/PIPE link with 2 lane(s) in use

Change the source so that lanes is defined with 4 instead. Please upload the (clean) syslog again and tell me what happens visibly?

Thanks!

(if you are unable to do it I'll change the code anyway for this change ;-)

[rudolfc]

Good morning from Holland :-)

In hrev55846 I changed the number of lanes to four. Please retest and upload the syslog.. Thank you!

[korli]

Sorry, I won't be able to check before about a week.

[rudolfc]

Hi, thanks for the heads up! Luckily the other ticket is the same system AFAICT, so testing is proceding in the meantime so far. The test I asked you for just now can be disregarded, the results are in, and git is updated again (hrev55848).

In the end it turns out the calcuations for the link are correct (1 lane), the driver sets the same divider as the BIOS, though with other numbers, which should work OK (I gained a bit more insight). From here on a few loose tests should be done disabling code, and forcing code to see if that would get us a picture, but this is becoming more and more longshots without access to the actual hardware over here, unfortunately. Still, a test or two I'll try to do before I quit on this panel. The code is much closer to be working OK now at least on your system ;-)

[rudolfc]

Hello, if you have time, you could test ​https://git.haiku-os.org/haiku/commit/?id=440667b4c6a6e93538270c835b164527e02331e9.

If all is right you should be having a working driver now.. If you do, please upload a syslog and let me know if all is OK.

Thanks you!

[korli]

syslog hrev55874 dirty

[korli]

Indeed, it works in native mode 60Hz (not 85Hz). Brightness settings work. I've also tested a non-native resolution. Thanks for the efforts.

[rudolfc]

You're welcome.

BTW: the timing and refresh will currently only be used from the mode requested when the resolution is native. While 84Hz doesn't work, I wonder if there are frequencies outside of 60Hz that -do- work, or if it's really limited to 60Hz only. If the latter is true, I should totally block these changes and always use the real exact modeline from the panel as found in it's BIOS.

If you have time to checkout how hard the 60Hz limit is then I'd love to hear how much you can/cannot change it (using the refresh slider that is)..

I think spec-wise I should block all modifications to the native modeline: still I am very curious what the internal panel can and cannot do ;-)

EDIT: so I am looking for both the lower limit and the higher limit..

[korli]

On Ubuntu, only 60Hz and 59.9Hz are available at native resolution, otherwise the frequency can't be chosen for non-native resolutions (the combox box disappears).

On Haiku, it works until 61.5Hz. Non-working frequencies should probably disabled.

[rudolfc]

Hi,

hrev55875 has exactly that. Please doublecheck it's now always working OK. The slider for refresh is the same, I'll keep it that way (in case someone uses a secondary screen it might be handy to not block it until we have dualhead support in app_Server).

[rudolfc]

Closing ticket as the eDP panel now works correctly. Feel free to reopen if needed. Thank you!