display panel turns to white

[starsseed]

At the moment of displaying the desktop (once all the boot icons have been successfully displayed/lit-up), the built-in flat panel shows random coloured dots, and then the screen gradually turns white within 1 or 2 seconds.

(ASUS Zenbook UX31E-RY009V)

[starsseed]

short syslog ASUS Zenbook UX31E-RY009V hrev55555

[starsseed]

now, with hrev55678 the intel_extreme driver seems to detect and set the correct panel resolution as shown in the log report:

KERN: intel_extreme: intel_get_preferred_mode
KERN: intel_extreme: intel_set_display_mode(1600x900, virtual: 1600x900)

KERN: intel_extreme: SetDisplayMode: DisplayPort A 1600x900

but the problem remains.

[starsseed]

intel_reg dump sandybridge (PCIID=8086:0116)

[starsseed]

here is a GPU regs dump from ubuntu. (if it can help) attachment:sandybridge_8086-0116_ubuntu_dump.txt​

[korli]

Registers look like #15746

[rudolfc]

Hi these register dumps are nice :-)

Anyhow, indeed this looks to be 'standard' DP programming. Your panel is detected on DP port A, and the driver detects its modeline from the BIOS: so looks like we need to use this modeline on sandybridge laptops for port A.

Generation detected is 6, not 7: so SandyBridge, not IvyBridge.

I'll have a look at the driver to see what I can come up with. With the new knowledge from DP programming on SkyLake etc maybe its now easier as well :-)

BTW: in your filtered syslog I see no PLL programming being done for instance. is the log complete indeed? Though if the older systems work in the same way as the newer systems the PLL would not need to be programmed, just the link, from the dump you added it's PipeA, which is already choosen by the driver (Based on BIOS preprogramming) so that's a good sign.

Thanks for reporting!

[rudolfc]

Update: yep, same situation on that other ticket. One solution probably solves both systems.

BTW I just remembered that I did already try to program the DP link on Ivybridge but failed some months ago: so I activated only scaling to the already set mode. This works nicely over here on Ivy, but apparantly not for these laptops.

I did succeed in programming DP links on G45 (gen 4), Skylake (gen 9) and Coffeelake (gen 9.5). I am going to retry this indeed..

[starsseed]

Replying to rudolfc:

BTW: in your filtered syslog I see no PLL programming being done for instance. is the log complete indeed?

I join a full syslog, in case I missed something: attachment:syslog-r55697.log​

[rudolfc]

Hi, just a heads up: I just committed working DP panel link programming for Sandy and Ivybridge. So I'm a step closer to getting your system running, but not there yet.

Currently portB,C,D should work, but not yet portA (eDP). I will come up with a dedicated DPlink routine for that (I think I now know how it should work), and kill the eDP code in the driver as it's more or less redundant from where I am looking.

When I have something to test I'll post it here again.. Will be a week or so I think.

[rudolfc]

Hello again, Could you please see what hrev55823 (or later) does for your laptop internal panel? With a bit of luck you could have a picture now..

If you try, please upload a syslog from the attempt. Thank you!

[starsseed]

Replying to rudolfc:

Hello again, Could you please see what hrev55823 (or later) does for your laptop internal panel? With a bit of luck you could have a picture now..

unfortunately, the problem persists.

If you try, please upload a syslog from the attempt. Thank you!

attachment:syslog-r55823-short.log​

[rudolfc]

Thank you. Behaviour did not go as I 'planned' looking at the log: could you on purpose try a non-native mode explicitly? i.e. 1024x768, but others are OK too, just try some..

Let me know if you get a picture on one of them, and upload a syslog from the attempt? Thanks!

[starsseed]

Replying to rudolfc:

could you on purpose try a non-native mode explicitly?

No, I can't, because on this laptop, I do not have access to the boot menu to choose an other video mode.

Let me know if you get a picture on one of them,

no changes with hrev55827 (native video mode)

and upload a syslog from the attempt?

here is the logs anyway. attachment:syslog-r55827-short.log​​

[rudolfc]

Ah ok. Can you try again with hrev55835 or later and upload a syslog again? A few more updates were done, and a logging update. I guess it will not work yet, but I'd love the log and your comment again :-)

Thanks a lot!

UPDATE: your new log might show me to a fault concerning lane# detection for 'FDI' (the driver says 1 lane is in use, but with your panel I suspect it would need 2) Also the transcoder is programmed which should not be I think, so I'll update that a bit as well for the next iteration.

[rudolfc]

Yes :-)

[rudolfc]

It shows an error indeed. You have I think 2 lanes to your panel, while programming thinks it's just one. So it cannot work indeed. I just pushed another update to the driver which paves the way to fix this problem (decoupling of the eDP link / FDI link M/N programming from the FDI link train stuff). Next up I'll only call M/N programming if PORT_A on gen 6 and 7. Still need to put in some time to see if I can dig up the settings from a register or two in your card though, but looks like gen6 misses stuff that gen7 does have, if so I am going to assume all gen6 eDP panels use 2 lanes fixed for instance.

I'll get back to you when I have some stuff in place for this :-)

[starsseed]

@rudolfc

After our lastest commit (hrev55836), here is the relevant changes in the syslog (if it can help)

KERN: intel_extreme: CALLED status_t FDILink::PreTrain(display_timing*, uint32*, uint32*, uint32*)
KERN: intel_extreme: PreTrain: FDI Link A:
KERN: intel_extreme: PreTrain: FDI Link Colordepth: 18
KERN: intel_extreme: PreTrain: FDI Link Lanes: 1
KERN: intel_extreme: PreTrain: FDI TX ctrl before: 0x40000
KERN: intel_extreme: PreTrain: FDI RX ctrl before: 0x20040
KERN: intel_extreme: SetFDILink: fPipeOffset: 0x0
KERN: intel_extreme: SetFDILink: FDI/PIPE link reference clock is 270Mhz
KERN: intel_extreme: SetFDILink: FDI/PIPE M1 data before: 0x7e684c75
KERN: intel_extreme: SetFDILink: FDI/PIPE N1 data before: 0x800000
KERN: intel_extreme: SetFDILink: FDI/PIPE M1 link before: 0x2e5ad
KERN: intel_extreme: SetFDILink: FDI/PIPE N1 link before: 0x80000
KERN: intel_extreme: SetFDILink: FDI/PIPE link colordepth: 18
KERN: intel_extreme: SetFDILink: FDI/PIPE link with 1 lane(s) in use
KERN: intel_extreme: SetFDILink: FDI/PIPE M1 data after: 0x7e34263a
KERN: intel_extreme: SetFDILink: FDI/PIPE N1 data after: 0x400000
KERN: intel_extreme: SetFDILink: FDI/PIPE M1 link after: 0x2e5ad
KERN: intel_extreme: SetFDILink: FDI/PIPE N1 link after: 0x80000
KERN: intel_extreme: CALLED status_t FDILink::Train(display_timing*, uint32)
KERN: intel_extreme: Train: FDI TX ctrl after: 0x40000
KERN: intel_extreme: Train: FDI RX ctrl after: 0x20040

and thank you very much for all your hard work.

[rudolfc]

You're welcome!

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

Thanks a lot!

[rudolfc]

Though I still wouldn't mind a syslogfrom the above mentoined hrev, I expect you'll have a better chance for a working screen with the new version I just committed:

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

[starsseed]

hrev55847 still shows a blank screen

attachment:syslog-r55847-short.log​​

[rudolfc]

Thanks! I am missing something in the calcs, we now have 3 examples, so I should be able to trace back my fault.. On it! :-)

[rudolfc]

Ok, I have to dryrun here these calcs, since when I do the math by hand all is correct (and only 1 lane is in use, so the registercontent can be used after all.. Must be a variable overflow somehow (uint32/uint64 or so)

[rudolfc]

Hi, back again: so in the end it turns out the initial calculations were correct, so I re-instated them with hrev55848. I propose you test this one again just to be sure we know what happens on your screen, and what the syslog says (upload it again please).

After we have confirmed this as a new reference point, I propose I upload a test version of the driver (or two) here which you can then install in the user unpackaged folder hierarchy in order to see if we can find out more about what's really going on. (I'll start with commenting out some code for you then).

That is, this is not going to work on UEFI systems: but yours is not UEFI I think? please confirm. Also let me know if you want 32bit or 64bit driver executables..

Thank you for your time and efforts again!

[starsseed]

Replying to rudolfc:

[...] I propose you test this one again just to be sure we know what happens on your screen, and what the syslog says (upload it again please).

Here is attachment:syslog-r55848-short.log​

Tell me if you prefer a full syslog.

I propose I upload a test version of the driver (or two) here which you can then install in the user unpackaged folder hierarchy in order to see if we can find out more about what's really going on. (I'll start with commenting out some code for you then).

I am at your disposal.

That is, this is not going to work on UEFI systems: but yours is not UEFI I think?

you are correct. I boot this laptop as a Bios system (even if this laptop is UEFI capable IIRC)

let me know if you want 32bit or 64bit driver executables..

as you can see in the log, I use a 64 bit kernel. So a 64bit driver.

Thank you for your time and efforts again!

it's the least I can do !

[starsseed]

I made a small video to illustrate what appends at boot.

​http://starsseed.free.fr/bug17350.mp4

[rudolfc]

Hi, Nice video, thanks! always helpfull indeed. The short log as you just now posted it is OK :-) Thanks. So programming works as expected (from the log). I'll upload a 64bit driver here asap. I'll include a syslog message so we can see it's running indeed. You know howto place a gfx driver in the user unpackaged hierarchy? Be warned though: if your system is -capable- of UEFI boot, that might already block this method (it does over here..)

So the way I am testing on UEFI-capable systems (even though I boot32bit BIOS version there!) is running a completely unpackaged system so I can place the driver in the system hierarchy..

[rudolfc]

driver test 1: don't program eDP link - 64bit.

[rudolfc]

Hi again, please see if you can get the just posted testdriver to work. it will print a message to syslog that it foregoes eDP link programming with 'test 1' in it as well. Once you see that message upload the syslog again and let me know what happens from your observations.

Since the BIOS probably (actually: does) programs the link already to the correct rate we can have one of two things I expect:

• driver now works correct (in which case the next test will be modified programming again for eDP link in a very specific way), or
• same behaviour as before (in which case there's still an unsolved and unknown problem).

Thank you!

[starsseed]

Replying to rudolfc:

You know howto place a gfx driver in the user unpackaged hierarchy?

Well, I'not sure for the path...
Should i copy the driver in system/non-packaged/add-ons/kernel/drivers/bin or in system/non-packaged/add-ons/kernel/drivers/dev/graghics ?

Be warned though: if your system is -capable- of UEFI boot, that might already block this method (it does over here..)

We won't know until I try...

[rudolfc]

in drivers/bin, and put a symlink to it in the other folder (mind the spelling mistake ;-)

Wow, that's a fast reply!

[starsseed]

Replying to rudolfc:

Wow, that's a fast reply!

Fast, fast... Not that much : 23h !
I was replying to the previous message.

[starsseed]

Replying to rudolfc:

Hi again, please see if you can get the just posted testdriver to work. it will print a message to syslog that it foregoes eDP link programming with 'test 1' in it as well. Once you see that message upload the syslog again and let me know what happens from your observations.

I can see SetDisplayMode: eDP port test 1: don't pgm eDP link in the log attachment:syslog-r55848-short-eDP_sandy_tst1_x64.log​ , but I still get the white screen.

Since the BIOS probably (actually: does) programs the link already to the correct rate we can have one of two things I expect:

• driver now works correct (in which case the next test will be modified programming again for eDP link in a very specific way), or

:-(

• same behaviour as before (in which case there's still an unsolved and unknown problem).

I get the same behaviour.

[rudolfc]

OK, I'll upload test 2 then: which will not program the mode at all, except for colordepth and framebuffer adresses. If the systems boots up with the native mode, you should have a display since this will block a lot of programming. After that we can re-enable piece by piece again in following tests to find the problem hopefully :-)

Test nr 2 coming up now, please test, upload syslog and let me know what you encounter, ok? Thanks!

[rudolfc]

test 2: dont program mode at all except for colordepth and frambuffer adress and width.

[starsseed]

same behaviour with tst2.

[rudolfc]

test 3: not modifing refclock setup / not programming mode (from test 2)

[rudolfc]

Please repeat ;-) So we have to go back even further: yet another programming routine disabled. This is a routine I never really looked at, just might be it..

[starsseed]

Replying to rudolfc:

Please repeat

same behaviour

Just ask !
;-P

[rudolfc]

test 4: block GPU downclocking (in kerneldriver) Also has test 2 en 3 in it (accelerant)

[rudolfc]

Asking :-) retest please, etc.. (even more disabled code: kernel driver: don't downclock GPU)

[starsseed]

Still no improvements with tst4.

[rudolfc]

test 5: block clock gating tricks/workarounds (kerneldriver) along with tsts 4,3,2.

[rudolfc]

Killed another kerneldriver register poke function..

[starsseed]

No changes with tst5.

[rudolfc]

test 6: blocking pipe enable/disable (Accelerant), along with 5,4,3,2: in both kerneldriver and accelerant.

[rudolfc]

This is a nice cooperation! Next up: pipe enable/disable block. A few more to go I think..

[starsseed]

Nothing new with tst6.
:-(

[rudolfc]

OK, now a seperate test, uploading current git driver here (PIPE useage detection added from BIOS, all code operational)..

[rudolfc]

normal git driver hrev55872 with added BIOS useage detection of Pipes for eDP on Sandy and IvyBridge, all code operational. 64bit. use both kerneldriver and accelerant..

[rudolfc]

Update: I'd love to see the syslog again so we know for sure the Pipe assignment is same or different from before set. I understand that you're getting tired, me too. (where do you live? I'm in holland and its getting about bedtime here :)

Anyhow: after this hrev55872 test I'll probably come up with an update on the actual pipe programming part (the mentioned hrev only has updated detection), and I indeed see now that here's a hard mistake, on a lot of chipsets I think. In order to get my attention to some thing like this all those previous tests were needed to rule large parts of the driver out (of the equation) so to speak. I really think (hope) we're getting close..

[starsseed]

Replying to rudolfc:

Update: I'd love to see the syslog again so we know for sure the Pipe assignment is same or different from before set. I understand that you're getting tired, me too. (where do you live?

I'm in France

I'm in Holland and its getting about bedtime here :)

I practice this kind of activity myself, from time to time...

[rudolfc]

Ah, you know the drill then :-) I take it still no change in behaviour?

[rudolfc]

Test 7: Dont touch BIOS setup refclk (test 3), Don't touch BIOS setup pipe assignment (test 7). 64bit.

[rudolfc]

Next up, disabled modifying BIOS preprogrammed Pipe selection. This code needs a complete rewrite as it turns out: on eDP port it's writing the wrong bits partially and touching the link config instead. Could be that it's not killing it (looks like that could be so), but at least it's really wrong programmed. Let's rule it out.

Please retest, upload log, and tell me what happens. Be sure to mentioned it even if you see small behaviour changes, as that might indicate we're on the right track. :-)

[starsseed]

Replying to rudolfc:

Please retest, upload log, and tell me what happens. Be sure to mentioned it even if you see small behaviour changes, as that might indicate we're on the right track. :-)

On boot up, I think I noticed a slight difference...
attachment:eDP_sandy_tst7_x64.png​

[rudolfc]

Ehh.. interesting? Do you mean to tell me it actually works this time?

I mean, it's a screenshot, no photo yet ;-)

[starsseed]

yes : it actually works.
:-D

[rudolfc]

Cool! So, do you have options to set other resolutions? How does it behave? Glteapot spins at 60hz? :-)

[starsseed]

Others resolutions works. The desktop is then stretched to fit the screen.
Others colormodes are ok.
For the refresh rate, at 1600*900 (native screen resolution) only 60hz works (but it's consistent with the specifications)
And Glteapot spins at 60hz.

[rudolfc]

Super! I will upload one more test driver for you then, I hope you will test it: the refclk code will be re-enabled in it, as I think it could be ok. Ok?

[starsseed]

OK, no problem.

[rudolfc]

Super! Uploading driver in a few minutes here. Please test and upload syslog plus your findings :-)

[rudolfc]

Final Test 8: All programming functional except programming Pipe assignment (uses BIOS done presetup). Should work on all systems btw. X64.

[starsseed]

Replying to rudolfc:

upload syslog plus your findings :-)

At the first boot I got a screen barely black. I mean the backlight was 0%.
Somehow, I succeeded in adjusting the brightness in the "screen" preference panel and then it was OK. (and I didn't got the black screen after a reboot.)
It seems the brightness is initialized with an incorrect value (see intel_set_brightness in attachment:syslog-r55848-short-eDP_sandy_tst8_x64.log​​ line 333)
I suspect that this problem is the cause of the bugs #13580, #15035, #15777, #16806, #17307 and #17456.
I think we should not allow a brightness < 10%

Also, in the "screen" preference panel, is it possible to disable refresh rates that are not compatible with the chosen resolution ?

[rudolfc]

Thanks for the hints. The refresh block is something I'll look into (already planned), but you will find already that this is only the case on the native resolution: all other resolutions are fixed at 60Hz (test please).

So, you mention the blackness thing and the slider: First I need to know from you if the driver behaviour differs between test 8 and test 7. Do they behave exactly the same?

Thanks for your work!

[rudolfc]

Oh, with fixed 60 I mean that independant of what you set in the screenprefs, the actual refresh remains 60Hz: you can verify that by:

• GLteapot framerate
• the fact than your screen keeps working, where it will shut-off if tried at native resolution.

Correct?

[starsseed]

Replying to rudolfc:

So, you mention the blackness thing and the slider: First I need to know from you if the driver behaviour differs between test 8 and test 7. Do they behave exactly the same?

test 8 and test 7 did not behave the same.
The test 7 showed me the desktop with a "normal" brightness at the first start. Note that intel_set_brightness is not called before the desktop is displayed (see attachment:syslog-r55848-short-eDP_sandy_tst7_x64.log​​​ before line 335)

[starsseed]

Replying to rudolfc:

The refresh block is something I'll look into (already planned), but you will find already that this is only the case on the native resolution: all other resolutions are fixed at 60Hz (test please). Oh, with fixed 60 I mean that independant of what you set in the screenprefs, the actual refresh remains 60Hz: you can verify that by:

• GLteapot framerate
• the fact than your screen keeps working, where it will shut-off if tried at native resolution.

Correct?

Well. I'm not sure I understand you...
I mean in the screenprefs, when I choose 1600x900@85Hz and apply, I get an scrambled screen. (the settings are reversed after a few seconds). When I set 800x600@85Hz, it works correctly.

[rudolfc]

yes, it will work correctly at 85Hz in a non-native resolution, because the driver ignores the refresh setting and keeps it at 60. You can recognize that if the teapot keeps spinning at 60Hz, and not 85.

OK: they did not behave the same: could you repeat testing both versions one or two times and see if the brightness thing fault turns up every time on 8, but not on test 7?

IF that's the case I think I should block the src-clk programming as well: it changes the link between your panel and the gfx card..

[starsseed]

Replying to rudolfc:

yes, it will work correctly at 85Hz in a non-native resolution, because the driver ignores the refresh setting and keeps it at 60. You can recognize that if the teapot keeps spinning at 60Hz, and not 85.

Yes, now i see what you mean. The teapot is effectively spinning at 60Hz

OK: they did not behave the same: could you repeat testing both versions one or two times and see if the brightness thing fault turns up every time on 8, but not on test 7?

I can't reproduce the black screen. it's just like if it was only the first time. Is there a setting file somewhere ?

[rudolfc]

Hi, thanks for doing the extra tests! OK, I'll leave the src-clk programming in place then and I will focus on the slider a bit instead. I'll upload a new driver in a few minutes: as it will be in GIT then. If all is right it works for you the same way as test 7.

The Pipe assignment code is functional again, but only on systems where it's actually supported (so it's blocked on your system i.e.).

Please let me know how it holds up. If all is right when the nightlies update they should work for you as well by default (apart from the slider stuff that is still)

Thanks! We had a nice weekend together I think :-)

[rudolfc]

current git driver with working eDP on Sandy and IvyBridge, 64bit.

[starsseed]

Replying to rudolfc:

Hi, thanks for doing the extra tests! OK, I'll leave the src-clk programming in place then and I will focus on the slider a bit instead. I'll upload a new driver in a few minutes: as it will be in GIT then. If all is right it works for you the same way as test 7.

For me the driver does the job and the problem described in the ticket is fixed.
I join the latest log file if you want to have a look.

Thanks! We had a nice weekend together I think :-)

Yes indeed. It was a pleasure to work with you.
Thank you for all your work. It is much appreciated.

[starsseed]

about the refresh rate:

Replying to rudolfc:

Thanks for the hints. The refresh block is something I'll look into (already planned), but you will find already that this is only the case on the native resolution: all other resolutions are fixed at 60Hz (test please).

the xrandr linux command give this :

Screen 0: minimum 320 x 200, current 1600 x 900, maximum 8192 x 8192
eDP-1 connected primary 1600x900+0+0 (normal left inverted right x axis y axis) 293mm x 164mm
   1600x900      60.00*+  59.99    59.94    59.95    59.82  
   1440x900      59.89  
   1400x900      59.96    59.88  
   1440x810      60.00    59.97  
   1368x768      59.88    59.85  
   1360x768      59.80    59.96  
   1280x800      59.99    59.97    59.81    59.91  
   1152x864      60.00  
   1280x720      60.00    59.99    59.86    59.74  
   1024x768      60.04    60.00  
   960x720       60.00  
   928x696       60.05  
   896x672       60.01  
   1024x576      59.95    59.96    59.90    59.82  
   960x600       59.93    60.00  
   960x540       59.96    59.99    59.63    59.82  
   800x600       60.00    60.32    56.25  
   840x525       60.01    59.88  
   864x486       59.92    59.57  
   800x512       60.17  
   700x525       59.98  
   800x450       59.95    59.82  
   640x512       60.02  
   720x450       59.89  
   700x450       59.96    59.88  
   640x480       60.00    59.94  
   720x405       59.51    58.99  
   684x384       59.88    59.85  
   680x384       59.80    59.96  
   640x400       59.88    59.98  
   576x432       60.06  
   640x360       59.86    59.83    59.84    59.32  
   512x384       60.00  
   512x288       60.00    59.92  
   480x270       59.63    59.82  
   400x300       60.32    56.34  
   432x243       59.92    59.57  
   320x240       60.05  
   360x202       59.51    59.13  
   320x180       59.84    59.32  
VGA-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)

So the embedded panel seems to support only ~60Hz refresh rate...

[rudolfc]

Hello again! Yes, Korli also tested refreshrate (he has exactly the same system you have) and 61.5 was the max working refresh on Haiku for him (you can test that by using the slider to find the lower and upper limit by trying.

I will block all refreshrates except 60 indeed, so I'll upload a new driver here, hoping you'll test it. The slider will remain the same, but if you set i.e. 85Hz the teapot should keep spinning at 60. The slider could also be blocked, but I won't do that now since if you connect a second screen it might be you would like to have a different refresh there (though it's currently a bit uncertain which EDID will be used for the external screen then).

I'll dive into the code again for the fixed rate :-)

[rudolfc]

hrev55875: eDP Sandy/Ivy panel modeline always fixed to native one, 64bit.

[rudolfc]

Would you please retest, upload log and let me know if on the 85Hz native mode setting, the display keeps working and the teapot keeps spinning at 60Hz?

Thank you, once more!

[starsseed]

With eDP_sandyIvy_hrev55875_x64.zip, at 70, 72, 75, or 85 Hz the embedded panel shows the desktop correctly,
but GlTeapot run at 47~48 fps instead of 60 !

[rudolfc]

Okee. I thought a bit about this, but this must be a problem with the vertical retrace detection, and not with the actual refresh onscreen, at least I expect so.

Could you try the following:

• set native mode @ i.e. 85Hz
• see teapot spin at wrong speed
• leave screen settings as is, reboot so system comes up with the i.e. 85Hz setting directly
• retest teapot spin rate: still same fault?

Thank you!

[starsseed]

Replying to rudolfc:

this must be a problem with the vertical retrace detection, and not with the actual refresh onscreen

I thought the same.

Could you try [...] native mode @ 85Hz [...] ?

After setting native_mode@85Hz and rebooting, GLteapot keeps spinning @ 47~48 fps.

[rudolfc]

Ok, from looking at the source I come to the conclusion the retrace interrupt nolonger occurs then. In this case the wait for the semaphore times out at 21mS: so 1000/21 = the rate you see.

Now I would like to ask you where it goes wrong, refreshrate wise: i,e, 65,70,75,80Hz? And what if you use a non-native mode?

So all in all the modesetting code is not the culprit here I think: that's good at least :-)

Thanks!

[rudolfc]

Oh, and another test: if you switch back to 60Hz refresh: does the teapot spin at 60 again as well? or does it remain at 48Hz?

[starsseed]

Replying to rudolfc:

where it goes wrong, refreshrate wise: i,e, 65,70,75,80Hz?

It appends for all refreshrate but 60Hz, and all these refreshrates gives a GLteapot spinning at 47~48 fps.

another test: if you switch back to 60Hz refresh: does the teapot spin at 60 again as well? or does it remain at 48Hz?

If I switch back to 60Hz refresh, the teapot spins at 60 again.
This behavior is happening immediately when I change the refreshrate "on the fly".(I mean while the teapot is spinning)

[rudolfc]

Thanks! Could you repeat that test for a lower refresh as well? so 55Hz and if possible 50Hz. In the meantime I'll try to reproduce the same error here (no luck yet) and I am finally looking real good at the interrupt code: which seems quite solid over generations: register and bitwise being correct.

Sofar my Ivybridge keeps working correctly, this is a desktop system but I enabled scaling on a fixed mode: but that works OK teapot wise :-)

[starsseed]

Replying to rudolfc:

Could you repeat that test for a lower refresh as well?

No, 60Hz is the lowest refresh rate available.

[rudolfc]

OK, thanks! I'll get back to you :-)

[rudolfc]

Hi again, In the meantime I was finally able to test the driver on all my Intel systems, I could not reproduce the refreshrate timing problem. Since at the intended 60Hz on your laptop panel it's working OK also, I suggest we close the ticket as the actual problem has been solved.

So: closing ticket. If you think I should not have done that, feel free to reopen it.

Thanks a lot for your help on this!