There are some devices that needs panel orientation quirks to get the display in the right orientation. Here is the list of devices https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_panel_orientation_quirks.c. The bgrt theme displays the fedora logo and the spinner in the right orientation but the efi bgrt logo gets painted in the default panel orientation. This happens also in restart/power off. I have tested a Lenovo Idepad Miix 310 and a Lenovo Ideapad D330. Also I think worth to mention that efifb kernel logo restoration paints it also wrong but in another way. efifb paints the width in the height and the height in the width making an effect similar to an interleaved image, but when plymouth bgrt shows up it repaints the entire screen so it's not a problem, but that suggest me that the rotation quirk only takes effect for intelfb and not efifb.
Thank you for the bug report. And also ugh, these devices with their LCD-panels mounted the wrong way are a pain. Note that plymouth already has code (I wrote it myself) to honor the quirks from drm_panel_orientation_quirks.c, but apparently that is not working here... Anyways lets see what we can do to try and fix this. I'm pretty sure I understand what you are trying to say, but to be sure, can you take a picture of plymouth (with your phone) and attach it here? I have access to the 310 and 320 models myself, for the 310 I'm not sure if I have the version with the rotated screen or not, I will check. Note that for the 310 Lenovo has 2 different BIOS-es for the version with and without the rotated screen and on the downloadpage they have vague instructions for which one you should get so possibly you or a previous owner have flashed the wrong BIOS. Can you do: "cat /sys/firmware/acpi/bgrt/status" on both models you have and let me know the output? Also do you have the exact same symptoms on both models?
p.s. I have an idea how I think I can avoid the efifb code drawing the logo with the wrong pitch (this will require a kernel patch). Can you also please do: "cp /sys/firmware/acpi/bgrt/image logo310.bmp" resp. "cp /sys/firmware/acpi/bgrt/image logo330.bmp" on both machines and attach the 2 generated files here? And also please do: cat /sys/firmware/acpi/bgrt/xoffset cat /sys/firmware/acpi/bgrt/yoffset On both machines and let me know the output (and which output is from which machine).
Is a pain for me not being a developer I can't imagine for you :) Yes the 310 as you say has two different BIOS that seems to change only the default orientation of the panel, I flashed both sometime ago before the panel quirks were enabled for this model and yes, it's better not to mistake with the one you need :) Just enabling the BIOS option to allow version downgrades it's possible to go from one to another. Also yes to the symptoms, both models have the same behavior given that for D330 at least kernel 5.2 kernel is used because the panel orientation quirk for it was initially applied to that version. Using any lower kernel at the time of writing D330 shows bgrt logo, spinner and fedora logo in the same orientation, but in the wrong one. I have tested 5,2 using Fedora rawhide live media. Here are the results from Miix 310: - status: 1 - xoffset: 480 - yoffset: 205 With the image and the values just as they are the logo it's in the right orientation and position. The ones for D330 I will post them tomorrow, I don't have access to it now, but, I remember that opening /sys/firmware/acpi/bgrt/image is in normal orientation as in the 310 but just much bigger as is the 1920x1200 model. For the efifb I applied the change you suggests in https://hansdegoede.livejournal.com/20632.html adding video=efifb:nobgrt, and just get black screen till plymouth shows up so, I will revert the change to give you feedback also for that.
Forget to mention that 310 is the 1280x800 version.
Created attachment 1591547 [details] efifb pitching This is how kernel restores the efi logo after grub menu.
Created attachment 1591548 [details] Plymouth bgrt theme over panel orientation quirk device It seems that the logo get positioned where it really should be and then it's rotated over that position. The orientation it takes is the panel natural orientation before the quirk is applied.
Created attachment 1591550 [details] Lenovo Ideapad Miix 310 logo as is in acpi Just "cp /sys/firmware/acpi/bgrt/image logo310.bmp".
This is for D330: - Screen resolution: 1920x1200 - status: 0 - xoffset: 576 - yoffset: 218 Taking the values makes the image to be in right orientation and position, but, D330 has status 0 instead 1. I have take the values twice, one with 5.1 kernel with no quirks for this model and another one with 5.2 with quirk enabled, the values are the same.
Created attachment 1591749 [details] Lenovo Ideapad D330 logo as is in acpi Lenovo Ideapad D330 logo as is in acpi Just "cp /sys/firmware/acpi/bgrt/image logo330.bmp". Just to be sure have checked the logo both in 5.1 and 5.2 kernels. The image is exactly the same as is in the efivars, no matter quirk enabled or disabled.
Created attachment 1591750 [details] Plymouth bgrt theme over D330 without quirk enabled This is how the theme is shown in D330 with kernel 5.1 with no quirk. The theme displays all the images in the same orientation but is the wrong one. The logo is well positioned in this situation, only we have the panel natural orientation.
Created attachment 1591751 [details] Plymouth bgrt theme over D330 with quirk enabled This is again D330 but with kernel 5.2 with the orientation quirk applied. It gets painted as in 310, the only difference is because the logo is so much bigger and it gets painted over the spinner. The logo is well positioned where it should be, but it's orientated in the natural position of the panel instead of the right orientation, same as the 310 with quirks.
I always forget something to mention, the D330 bgrt theme images are take while powering down the system, as there is yet a bug https://patchwork.freedesktop.org/patch/317041/ to be solved in kernel that makes the screen go black when i915 loads, but the result should be the same as in 310 always, with quirks and no quirks have had the same behavior plymouth while booting, restarting or powering off.
Thank you for all the info. I've been working on this today, it turns out that at least my own Miix 310 is also hit by this (I expect the 320 to be the same but I still need to test). The efifb situation is not the pitch of the logo being wrong. The firmware is buggy and is telling us that the efifb has a size of 1280x800, which should really be 800x1280, so the pitch of the entire fb is wrong rendering it useless. Luckily we have seen similar efifb issues on the first EFI based macbooks, so we already have a quirk mechanism in place. I'm almost done with writing kernel patches which fixes the efifb (by overriding the wrong firmware provided size + pitch), so that e.g. a kernel panic on a corrupt initrd will actually be readable... I expect to need a quirk similar to the Miix 310 one for the 320 and for the D330. For this quirk I need some additional info on the D330, can you do the following: Directly after boot do "dmesg > dmesg-d330.log" and then attach dmesg-d330.log here? And also please as normal user do: grep . /sys/class/dmi/id/* 2> /dev/null And copy and paste the output here.
I also have a plan for fixing the plymouth side of things, hopefully I will be able to finish that up this week. I'm going to be busy with other stuff next week, so if I'm quiet for a while, that is why. I will get back to you the week after.
I just realized that I have the necessary info for the D330 efifb quirk in the existing rotation quirk, so I've taken it from there and updated my patch adding the efifb quirks for the miix 310 and 320 to also add a quirk for the d330. I've started a kernel scratch/test build with the patches added here: https://koji.fedoraproject.org/koji/taskinfo?taskID=36344683 For good measure I've also added the fix from: https://patchwork.freedesktop.org/patch/317041/ to this build :) Please give this kernel a try on the D330, generic instructions for installing a kernel from koji are here: https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt Note it will take a while (a few hours) for the build to finish. Please also try this kernel with "nomodeset" on the kernel and then in plymouth while the spinner is shown press esc to get details this should show various text messages (the purpose of this test is to test that the efifb now is correctly setup and the textconsole works properly on efifb with the patched kernel).
I've also managed to fix the plymouth issue, I'm pushing an update for this to updates testing now. If you do not want to wait for the update to hit the updates-testing repo, then alternatively you can grab it here: https://koji.fedoraproject.org/koji/buildinfo?buildID=1315245 Note after updating plymouth you need to regenerate your initrd using: sudo dracut -f This will regenerate the initrd for the kernel you are currently running, so if you've just installed a new kernel you need to reboot. If you are going to test both the scratch kernel-build and the new plymouth at once, update plymouth before installing the test kernel.
FEDORA-2019-02912d2d67 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-02912d2d67
Thanks a lot in advance for your efforts. I was just about to send you dmesg and dmi values. You still need dmesg output? I think I'm not going to have time to compile and test till Monday. Another related but offbug question. I did the orientation quirk for the 1920x1200 because is the one I have, but seems that the 1280x800 version have the same dmi values. I will try to ask people in Lenovo forums to confirm it. ¿Could something like this work for both models at the same time? There is a comment that says the resolution is also checked to apply or not the quirk. ... }, { /* Lenovo Ideapad D330 (HD) */ .matches = { DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"), DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "81H3"), DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad D330-10IGM"), }, .driver_data = (void *)&lcd800x1280_rightside_up, }, { /* Lenovo Ideapad D330 (FHD) */ .matches = { DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"), DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "81H3"), DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad D330-10IGM"), }, .driver_data = (void *)&lcd1200x1920_rightside_up, }, { ... Also there is Lenovo Ideapad D330s with 81MD model number instead 81H3, but I haven't known nobody with one of them.
My bad, I understood I will have to compile it, I think I will have time to test this weekend as If I haven't miss this time is just to install the rpms from koji.
(In reply to David Santamaría Rogado from comment #18) > Thanks a lot in advance for your efforts. > > I was just about to send you dmesg and dmi values. You still need dmesg > output? > > I think I'm not going to have time to compile and test till Monday. > > > Another related but offbug question. I did the orientation quirk for the > 1920x1200 because is the one I have, but seems that the 1280x800 version > have the same dmi values. I will try to ask people in Lenovo forums to > confirm it. > > ¿Could something like this work for both models at the same time? There is a > comment that says the resolution is also checked to apply or not the quirk. > > ... > }, { /* Lenovo Ideapad D330 (HD) */ > .matches = { > DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"), > DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "81H3"), > DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad D330-10IGM"), > }, > .driver_data = (void *)&lcd800x1280_rightside_up, > }, { /* Lenovo Ideapad D330 (FHD) */ > .matches = { > DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"), > DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "81H3"), > DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad D330-10IGM"), > }, > .driver_data = (void *)&lcd1200x1920_rightside_up, > }, { > ... > > Also there is Lenovo Ideapad D330s with 81MD model number instead 81H3, but > I haven't known nobody with one of them. Ugh, yes that should work, for the panel_orientation_quirks stuff, but not for the quirks to fixup the efifb size, see: https://github.com/jwrdegoede/linux-sunxi/commit/e6f1fb89c6d433f68bcd7c9097be4ee4e67b88a9 I guess we need a new OVERRIDE_SWAP_WIDTH_HEIGHT flag for the efifb quirks, that should work for both resolutions... Anyways please let me know if my current patch works for the FHD version.
I have tested 310, till tomorrow I couldn't try 330. I have done your tests and I could see the following, I guess that most are normal when using nomodeset: - efifb doesn't do bgrt restoration despite I have checked I'm not disabling it with nobgrt parameter (even booting with modeset restoration doesn't happen, the logo is first displayed by plymouth). - plymouth uses the fallback theme (3 dots) for booting but they are not centered as normally. - text output works as it should (so we now can interact with dracut as you wanted). - when wayland starts it does with the wrong orientation and the screen resolution in settings shows as 800x1280 (it gets corrected when booting with modeset by orientation quirks). - there is no support for autorotating the screen, even there is no autorotation lock icon in gdm/gnome options menu. - when powering off or rebooting plymouth shows bgrt theme but in wrong orientation. To be 100% sure we have good output with dracut initramfs I have tried unsetting quiet and rhgb and it works as it should. Just to know, could be a way to swap the resolution height width for efifb to make it work similar to intelfb? Even if there is a way I think as is now it's all ok because the normal situation is going to be use modeset, I don't know no use case without it. Tomorrow will report with 330. PD: If you wish I could separate this in another more bug report, leaving this for plymouth that works perfect with your -7 update, and a new one for the efifb issue.
plymouth-0.9.4-7.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-02912d2d67
The nomodeset testing is only meant to check that the efifb / textconsole-on-efifb is functional. The other issues can be ignored (normally one would not use nomodeset). The new kernel and plymouth should otherwise be tested normally (so without nomodeset). I've started a new scratch-build, this time based on the 5.2 kernel so that the D330 drm_panel_orientation_quirks.c entry is actually there and with a new version of the efifb fixup patch which swaps the width and height so that it should do the right thing for both panel-resolutions found on the D330. Please give this new version a try on the D330 when it has finished building: https://koji.fedoraproject.org/koji/taskinfo?taskID=36364710
While waiting for the 5.2 I have tested the 5.1.18. Works as expected, legible output just wrong orientation and also the pending patch for Gemini Lake works, no need to suspend detach reattach keyboard while doing a handstand to get DSI graphical output to work. The only remarkable thing then is there is no bgrt logo restoration in efifb but at least for me that is not important. In summary your code works for D330 FHD. When I test the new kernel with orientation quirk will also report. Good work Hans, I didn't expected this could be solved that fast.
Tested with 5.2 works as expected and also not bgrt restoration in efifb. I could even see when a warning is triggered at boot by using modeset removing quiet and rhgb. It was appearing in gnome through abrt. The dmi values for hd version have been posted here https://bugs.freedesktop.org/show_bug.cgi?id=109267#c71 and seems to be practically identical, only seems to change BIOS version and board_version. Perhaps board_version could be used, but maybe there are many ones, HD and FHD have variants, with without lite gps, different memory/disk sizes... One more thing is that I could see a bug reported for plymouth here. In D330 is possible notice glitches that seems to be causes because the scale size. When using nomodeset spinner and logo has the normal size and no white line appears, but using modeset scale size is applied and also a little flicker happens in spinner and a little white line is shown.
One more thing I didn't remember till now. When booting windows from grub, the lenovo logo and the windows spinner in painted with the wrong pitch, seems that the windows loader alter the efi vars or something because when boting windows directly from uefi it paints right. Also noticce that in this laptops, the windows recovery mode is always in the panel's natural orientation. Haven't seen in Miix 320m but I guess it does too.
plymouth-0.9.4-7.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
Thank you for testing, I've submitted the efifb width / height swap and pitch fixup patch upstream now. Also thank you for the link to the dmidecode for the 800x1280 version, that info confirms that the quirk which you tested should also work on the 800x1280 version as the tested DMI strings are the same. About the plymouth glitches, yes I'm seeing those too one some devices which plymouth considers HiDPI (5.5" 800x1280 screen, resp, 10" 1920x1200 screen) I have looking into these on my TODO (but not as a high prio item, so it may be a while before I get around to these). A bug has been reported upstream for this: https://gitlab.freedesktop.org/plymouth/plymouth/issues/83 About the Windows issue when Windows is started by grub, weird this indeed suggests that Lenovo has hacked the windows bootloader to fit the efifb bug somehow??? Anyways nothing we can do about that. About the kernel fixes, I've marked both fixes Cc: stable.org, so they should show up in a 5.2.z kernel release I hope. I might add them as local patches to the Fedora kernel builds once they have been through upstream review. In the mean time I suggest you stick with the 5.2 scratch build I did.
Great approach the new one, I think it will be accepted with no problems, the first one could be rejected upstream because the lenovo dmi check to bypass the condition, but the new patch you did seems so good.
About the Windows startup I don't think Lenovo patched the loader, because it's overwritten with windows updates. I think more in something like microsoft swaping all the portrait resolutions or something similar. One interesting thing is in the release note of the last bios update for the d330 - Version 8NCN35WW: 2. If you want to update this version of the BIOS, you should make sure that the driver version of your VGA is 24.20.100.6292 or newer.
Hans I have found something in dmesg that explains why bgrt restoration is not done. Without pitch correction efifb says: efifb: showing boot graphics With pitch correction: efifb: Ignoring BGRT: unexpected or invalid BMP data Could be possible that the pitch correction conflicts with the BGRT extraction?
It seems to be that efifb when checking the offset plus the image offset fails because the corrected pitch, I compares the width with the height and then fails because it seems to get out of bounds.
offset plus image size*
(In reply to David Santamaría Rogado from comment #31) > Hans I have found something in dmesg that explains why bgrt restoration is > not done. > > Without pitch correction efifb says: > efifb: showing boot graphics > > With pitch correction: > efifb: Ignoring BGRT: unexpected or invalid BMP data Right, that is by design, the test kernel build I gave you actually has a patch to ensure that the "invalid BMP data" path gets hit. The efifb does not know the logo needs to be rotated and it has no support for rotation at all. So without this extra sanity check it will display the logo (*), but with the wrong orientation and offsett-ed a lot to the right, almost against the right edge. So as said I've added an extra sanity check to the test kernel to make sure that the "invalid BMP data" path gets hit. If the grub menu is not shown, there is no need to restore the logo and if the grub menu was shown then the screen will just stay black a bit longer until plymouth kicks in. Both scenarios clearly beat showing the logo with the wrong orientation and teaching then efifb code to fix things up and do rotation itself is not worth it for the handful of devices with this issue. I actually wrote the efifb bgrt restoration code for some Bay Trail based devices which do not show the logo themselves at all, so there the user would be looking at a black screen after power-on for quite a long while. This is not the case here, so I went for the easy fix of disabling the efifb bgrt restoration code on these devices. I hope this helps explain what is going on. *) The logo fits, it is a tight fit, but it fits so it does display it
Understood, I thought it wasn't going to be needed to rotate the bgrt logo. Anyways as you said I even have made a custom grub-bgrt themes using darac's script on github as base, and miix 310 have a completely flicker free boot. With the D330 seems to be problems with the dsi video output initialization doing some strange artifacts when intelfb is set, but I imagine that is gemini lake code issues because even forcing fastboot they stay. For D330 also I'm using refind because the miix 310 use vol keys as up down and power as enter key in bios and efi boot managers, but D330 fails to do it, so using it as tablet at boot the only way I have found to choose the so is refind with touch support activated (another way could be to force the efi boot selection of the firmware, but I don't want it :)). I'm staying with your kernel till your patch and Stanislav's gemini clock fix arrives, I have seen yours is now upstreamed in 5.3-rc1, good and fast work Hans.
I have been trying HackBGRT to change the default bgrt image from lenovo, first to a only white letters without the outlandish background and later testing with some other images. Some images makes plymouth to render them in the incorrect orientation, for examples in the D330 a 478x443 image positioned at x=721,y=178 get rendered in the default panel orientation. Also I have observed that there is a little flicker in plymouth showing very fast the last screen output before intelfb starts. While testing different images I sometimes forget to change the logo in the grub theme and then is when the flicker is visible, if the image is the same is very difficult to notice. I'm going to wait for this as it could be i915 issues and newer kernels seems to have display patches in i915. Also the glk clock divisor patch is now in linux-next.
The flicker between the video output just before intelfb is loaded also happens when shutting down, somewhere in the video memory It gets placed.
About what you call "the flicker": When nothing (neither plymouth not X/Wayland) owns the framebuffer / gives the kernel a framebuffer to scanout, then the kernel will fallback to the initial framebuffer passed to it by the firmware. So what you are seeing is not a flicker in the sense of a modeset, it is you briefly seeing the firmware framebuffer contents or the BGRT logo as restored by efifb. As you've noticed during boot there is a short time when no one owns the fb: And there are 2 brief moments when no userspace app owns the framebuffer on shutdown/reboot: 1) Transition from user's graphical session to plymouth 2) plymouth quitting shortly before shutdown/reboot This is why the flickerfree boot theme incorporates the BGRT logo so that the user does not see these unowned moments, since the fallback fb has the BGRT in it (if all is well). As for plymouth not always picking up your custom BGRT graphics, plymouth expects the following to be true (in native un-rotated coordinates); Normally, pre-rotated image (or upright panel): xoffset = (panel_width - bgrt_width) / 2 Special case for the Lenovo-s from this bug, where the panel is mounted 90 degree rotated, but the BGRT is not pre-rotated: xoffset = (panel_height - bgrt_width) / 2 With all widths / heights in pixels. If your custom bgrt matches neither then plymouth will assume it is pre-rotated and it will center it itself, ignoring the xoffset and yoffset you have specified. This is done this way because the xoffset / yoffset are really only valid for the efifb resolution which sometimes does not match the native panel resolution. If you make your custom BGRT xoffset match one of these 2 rules (depending on whether it is pre-rotated or not) then plymouth should do the right thing If you make it match the first rule (so pre-rotate it) then efifb will also redraw it in case something, e.g. grub has destroyed the firmware's own drawing of it.
That's for all the information about the framebuffer management, it's very interesting. I mislead the centering of the image, I leave native x instead auto (now x=721), so indeed it wasn't centered. D330 do not show bgrt itself (this makes possible to only show the HackBGRT defined images from the beginning), so the first graphic output I watched was the grub menu, and there I set up correct values. Correcting the x value to be centered does what you said. I have even set up a bgrt that get in of bounds in the 310 so I could even see efifb restoring it also as you said, wrong orientation and too much upper left. Thanks one more time for all the time you spend. PD: I could see in another bug people arguing about not wanting bgrt theme because the bgrt image defined by the manufacturer, forward them to HackBGRT so they could choose the image they want if spinner is not an option for them. Is not risky because there is no firmware overwrite, and in some systems the stock image doesn't show at all, and in other ones only just a little moment at bios start.