Linux GOP initialization is wrong

Linux GOP initialization is wrong

[David Santamaría Rogado]

This is related to the issues at least on some devices for panel
orientation quirks where added.

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.

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.

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.

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.

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.

I still have to test what Windows do if I try to boot it with the
video mode 0 active instead the default firmware mode 5, but I guess
it just select the highest resolution available where the x > y, and I
don't think this is the perfect approach, if some manufacturer wants
to make a portrait booting device it only will be possible by
respecting when the resolution is portrait or landscape while
searching the highest of them.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux GOP initialization is wrong

[Hans de Goede]

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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux GOP initialization is wrong

[David Santamaría Rogado]

Hi Hans,

I also found something interesting with that tests, the bgrt is not
painted in the same position when doing the EFI Shell rotation, the
firmware seems to take into account to position it. That solved me one
thing I could not understand, Windows recovery system uses the
incorrect orientation but handles it well and also the position of the
bgrt. When booting with the Shell rotated plymouth paints the logo how
is in the Windows recovery.

When booting Windows even rotated, I cannot be 100% sure if it does a
modesetting change like with an old crt because the flicks and the
cathode sound but I think when the drivers are set up it does a gop
mode setting change.

The vnc issue I found it just because I started playing around with
gnome boxes, the display send have the same effects as it have an
incorrect pitch.

I will try to know to compile my own fedora kernel to try to test
something about this. Even if there are problems with other devices,
could be possible to do something like the dmi tables for the gop part
in the kernel to apply modes for specific devices if it works?

El mar., 28 abr. 2020 a las 10:45, Hans de Goede
(<hdegoede@redhat.com>) 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux GOP initialization is wrong

[David Santamaría Rogado]

[-- Attachment #1.1: Type: text/plain, Size: 6794 bytes --]

Anyway, what you say is what I thought, goo video mode is not being
modified by the kernel, but, the problem is that we take then the first
available mode we can found, so the problem is we take, in devices where
the default video mode is not the first one in order, the wrong mode. So
efifb is thinking the mode is 1200x1920 when in fact we are in 1920x1200.
We don't need to change the active video mode, just find the real video
mode that is active when the kernel start up.

El martes, 28 de abril de 2020, Hans de Goede <hdegoede@redhat.com>
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
>
>

[-- Attachment #1.2: Type: text/html, Size: 7675 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux GOP initialization is wrong

[David Santamaría Rogado]

I'm thinking also about the i915 part. Could be something different
that Intel does in the Windows version of their driver? Seem very
strange that Microsoft could patch something because of this
particular hardwares.

El mar., 28 abr. 2020 a las 10:45, Hans de Goede
(<hdegoede@redhat.com>) 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux GOP initialization is wrong

[Hans de Goede]

Hi,

On 4/30/20 3:22 AM, David Santamaría Rogado wrote:
> I'm thinking also about the i915 part. Could be something different
> that Intel does in the Windows version of their driver? Seem very
> strange that Microsoft could patch something because of this
> particular hardwares.

On Windows devices often ship with vendor modified drivers,
for the graphics driver Intel even allowed the vendor to
ship its own driver and opt out of generic Intel driver
updates (this changes very recently).

Also chances are that this is all controlled by some registry
setting, so as long as the device ships with the registry
setting telling the driver to deal with this, then on upgrades
of the driver, the driver will still see the old registry setting
and behave accordingly. I've very carefully checked the VBT
(Video Bios Tables) and I see no hints there which the windows
driver could use. So I believe that this is taking care of
with device specific settings done by the device's vendor.

Regards,

Hans



> 
> El mar., 28 abr. 2020 a las 10:45, Hans de Goede
> (<hdegoede@redhat.com>) 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel