intel_extreme: image shrinks instead of displaying selected part when framebuffer size is bigger then video mode size

[X512]

This is hrev54942.

When framebuffer size is larger then video mode size, only part of framebuffer is supposed to be displayed. Visible part can be selected with B_MOVE_DISPLAY. This is required for implementing hardware double buffering and rearing-free rendering.

See screenshot: ​https://discuss.haiku-os.org/t/videostreams-media-kit-like-3d-hardware-acceleration-kit-for-haiku/11139/34.

[rudolfc]

There was an error in the driver mixing up h and v timing with virtual width and height. Fixed in hrev55419.

Please retest.. If still not OK it's probably due to your card not yet being supported ok enough.

[rudolfc]

Haswell has another way to set X,Y offset in the framebuffer as shown here by X512:

​https://discuss.haiku-os.org/t/improving-the-intel-extreme-driver-was-graphics-on-dell-laptop-in-vesa-mode-only/10583/215

'Old' register INTEL_DISPLAY_x_BASE don't exist in Haswell anymore. Instead they have a different implementation of the earlier also already existing register INTEL_DISPLAY_x_OFFSET.

Updating driver for this now..

[rudolfc]

Updated git: hrev55436. Please retest the driver X512 and see if it's operational without your patch now.

[X512]

Vertical scrolling seems work fine. Horizontal scrolling is not yet tested.

[rudolfc]

Closing ticket after commit hrev55454.

Fixed:

• cloned accelerants (missing shared_info currently set mode),
• panning and scrolling with virtualscreens,
• BWindowsScreen panning and scrolling: has B_SCROLL flag set in driver now.
• horizontal panning glitches due to error in offset calculations on most cards before haswell.

Feel free to reopen if something is still wrong.

Thanks!

[Pinaraf]

On Intel Atom CPU N230 with its i945 GPU, the fixes mentioned here completely breaks the display: it flickers and fills only a part of the screen. I bisected this down to the commit hrev55419, and reverting the changes in Pipes.cpp is enough to bring it back to normal.

I am often available on IRC and would be happy to test further fixes.

[rudolfc]

Hi,

This sounds very strange to me. OTOH: did you try a fresh recent nightly? Since only updating will keep the old modeline in place the app_server is using, which might be the 'real' cause of this.

You can also try what happens if you delete the vesa and app_server settings files and reboot. If all is right the system will re-determine the initial mode.

Aparantly you are having trouble on a change of the non-visible part of the modeline, so that warrants this test I think.

[rudolfc]

BTW: please add more details about your system, including a syslog..

[Pinaraf]

Broken display on i945

[Pinaraf]

Hi

When booting the latest nightly from USB, the issue is exactly the same. I will attach the complete syslog in a few seconds. I don't know what additional information you could need other than the CPU/GPU, so do not hesitate to tell what more you need. I can even arrange for an SSH access to the machine if it can help.

[Pinaraf]

syslog

[pulkomandy]

On i945 and older generations, I think we need to always program the southbridge to use the LCD native resolution, and the northbridge to use whatever resolution we want to display. The panel fitter is somewhere between the two, and will do the conversion.

If I remember correctly, this is done with the hardwareTarget mode that is used to program the southbridge side, and is always copied from the EDID data. However I'm not sure if this mode is fully initialized with all fields in the structure. I think reverting the changes in LVDSPort::SetDisplayMode that touch hardwareTarget, at least for this chipset family, should help with this.

[rudolfc]

If I remember correctly, hardware target, when targeting a LVDS panel, is -not- the default native modeline per definition in practice: that indeed should probably be forced, as long as this is the only spot we 'undo' commits: since otherwise you'll break a lot/a number of other systems again.

One important missing piece of info here was that this is laptops we are talking about btw ;-) Another one is I expect (seeing trouble I am seeing myself on gen9), if the systems are tested with uefi or non uefi hardware, and if it was 32 or 64bit haiku. Since uefi / x64 foregoes a part of the gfx card init functions, I'm afraid we will see more trouble in that regard, but this is for another ticket or so also)

I'll have a look in a day or two, at least, I'm quite busy with other things atm.

On a 'sidenote', I think this should not have been a reopened bug, as it is clearly not the same bug X512 was seeing.

[pulkomandy]

Yes, I agree, this should be a separate ticket.

The hardware target is clearly set to the panel mode in this case (coming either from EDID data or from finding it in the BIOS):

hardwareTarget = gInfo->shared_info->panel_mode;

It could also be that this mode is incorrect in the BIOS of this particular laptop, or that EDID did not work (that is the case for some eeePC designs, where for some reason they did not wire EDID to the graphics chipset but somehow decided to wire it to the embedded controller in place of a PS/2 port). Indeed knowing the exact laptop model would be very helpful to investigate the possibility of something similar here.

[rudolfc]

Ok, well, iirc I saw something about this not being forced hard enough, so I'll double-check that asap. Otoh, you have such a laptop pulkomandy? In that case maybe you can have a closer look :-)

[Pinaraf]

I can open another ticket if you want. My laptop is a Lenovo Ideapad S 10-2, it's old enough that it has no UEFI.

[pulkomandy]

Actually yes, I did find one in my pile of hardware. I'll see what I can do.

[pulkomandy]

​https://review.haiku-os.org/c/haiku/+/4664 should fix the problem.

[rudolfc]

Ah ok, that I did not recognize indeed. Stupid mistake, 😐 sorry about that. Thanks for checking! If Intel docs concur (will no doubt be the case) then by all means, commit the patch. Thanks for checking!

[Pinaraf]

I confirm this patch fixes the issue on my hardware, I can not confirm for other generations.

[pulkomandy]

Unfortunatly there are no docs for these older generations of hardware :( So it's a lot of guessing and comparing with Linux drivers.