El martes, 28 de abril de 2020, Hans de Goede <hdegoede@xxxxxxxxxx> escribió:
> Hi David,
>
> On 4/28/20 1:58 AM, David Santamaría Rogado wrote:
>>
>> This is related to the issues at least on some devices for panel
>> orientation quirks where added.
>
> Thank you for looking into this.
>
>> My tests have been done over a Lenovo ideapad D330.
>>
>> This devices like the other ones that need panel orientation quirks,
>> shows the initramfs with wrong stride and x and y swapped. By applying
>> the panel orientation quirks this gets solved but many parts of the
>> systems components needs to be patched. Hans has done a great job with
>> plymouth, mutter... but always appears a new problem derived as for
>> example vnc desktop sharing with this devices doesn't work and the
>> output is send messed up.
>
> When I first started adding support for devices which have their
> screen mounted 90 degrees rotated my first attempts where aimed
> at solving this transparently in the kernel.
>
> Unfortunately this is not possible. On most affected devices
> the hardware does not support 90 degrees rotation for the
> primary display layer; or if it does this requires the framebuffer
> being in a hardware-specific tiled format rather then being a
> linear framebuffer. Using these tiled formats requires userspace
> to be aware of this, which rules out transparently handling this
> in the kernel.
>
> Other layers (cursor layer, video overlay layers) have similar
> issues which require userspace to be aware of what is happening,
> so unfortunately there is no other way to deal with this then
> fixing involved userspace components.
>
> I'm a bit surprised that you sat that vnc desktop sharing does
> not work, I guess that also depends on how the desktop sharing
> works. If it pokes directly at the framebuffer somehow, then yes
> it will be messed up. But if it goes through the display server
> then things might work. I guess that it is possible that the
> code doing this cannot deal with Xrandr output rotation ...
>
>> The strange thing is that bootloaders like GRUB or rEFInd seems to be
>> able to handle this and they paint themselves right, despite when
>> booting Windows directly Windows paints itself right and booted with
>> GRUB or rEFInd the first second also paint itself wrong. Haven't
>> tested this too much but the interesting thing is in the next
>> paragraph.
>
> My experience with bootloaders showing themselves the right way
> up is mixed. It seems that the firmware is doing some hacks for
> this on some devices, at least for the EFI text console.
>
> Funnily enough (for some definition of fun) on at least one of
> the devices where the firmware is playing tricks (Asus T100HA IIRC)
> the position of the carret for text-editing is off by one, which
> is very annoying when editing the kernel commandline and which
> clearly shows that things are being emulated in software here.
>
>> I decided to get the UEFI GOP video modes and found that the D330 have
>> these ones:
>> Mode 0: 1200x1920
>> Mode 1: 640x480
>> Mode 2: 800x600
>> Mode 3: 1024x768
>> Mode 4: 1920x1200 (this is the default one started by the firmware)
>> Mode 5: 480x640
>> Mode 6: 600x800
>> Mode 7: 768x1024
>>
>> So I thought that Linux is taking the first mode despite is not the
>> active one and that's why the display is messed up.
>
> Nope, Linux does not touch the mode at all (nor does grub by default).
> Doing a EFI/GOP modeset has the risk of triggering all sort of firmware
> bugs. So we stick with what we get. This has interesting side effects
> where on some systems you get a different mode when turning on the
> machine and letting it boot, vs turning it on, pressing e.g. F12 to get
> the boot menu and then boot Linux.
>
>> Playing a little I could modify the GOP video mode before booting with
>> the UEFI Shell by simple using the mode 150 101. This causes GOP video
>> mode 5 to be switched to video mode 0, the first one. Booting now
>> makes initramfs messages to be correctly rendered but in the wrong
>> orientation.
>
> Right, the rendering on the side thing is expected. As said the hardware
> cannot do 90 degrees rotation with a linear framebuffer and the GOP
> provided efifb is a linear framebuffer. So without telling the kernel
> to software rotate its text console the text will always be on its side.
>
> What your little EFI shell hack is doing is working around what seems to
> be a bug on these Lenovo devices gives us the wrong stride and dimensions
> for the EFI framebuffer.
>
> Note that this very much is a Lenovo bug, all the other devices
> with 90 degree rotated screens let us render the text console
> on its side just fine. They correctly tells us the real size
> and stride of the screen (so its portrait dimensions since it
> is a portrait screen).
>
> Even though this is a Lenovo bug we should probably still try to
> find a way to deal with this though, so that the efifb works
> correctly on these devices...
>
>> A look at drivers/firmware/efi/libstub/gop.c seems to be what is
>> happening, the first available video mode is used despite it could not
>> be the active one in GOP and the active mode is not switched to the
>> discovered one by Linux. Both GRUB and rEFInd are able to respect the
>> video mode that GOP has active so it's possible to boot them landscape
>> and portrait while being correctly rendered.
>>
>> I think the video mode should not be the first discovered one but the
>> active one, or at least, the highest resolution video mode that
>> respects the orientation.
>
> Again, Linux does not use the GOP concept of video modes at all,
> it simply takes the active mode as reported by the UEFI and uses
> that to show messages during early boot.
>
> Also note that fixing the efifb is of little value early during
> boot the kernel will load the i915 driver so that we can have
> hardware rendered 3D, support for multiple monitors, etc. and as
> soon as that is loaded the efifb settings no longer matter.
>
> The i915 driver does not care about the GOP settings at all;
> and without a quirk it too will cause everything to be rendered
> on its side.
>
> Regards,
>
> Hans
>
>
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
