Fwd: absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers produce vast raster right and bottom borders on the larger resolution of two displays

Fwd: absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers produce vast raster right and bottom borders on the larger resolution of two displays

[Bagas Sanjaya]

Hi,

I notice a regression report on Bugzilla [1]. Quoting from it:

> Original Summary:
> absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers produce vast raster right and bottom borders on the larger resolution of two displays
> 
> To reproduce:
> 1-connect two unequal native resolution displays to a Tesla or Firmi GPU
> 2-don't have plymouth in use (I don't ever have it installed, so don't know whether it impacts)
> 3-don't include e.g. video=1440x900@60 directive on Grub's linu lines
> 4-boot Tumbleweed or Fedora 38
> 5-switch to a vtty, e.g. Ctrl-Alt-F3
> 
> Actual behavior:
> 1-Both displays utilize the resolution (same pixel grid) of the lower resolution display
> 2-Lower resolution display behaves as expected (light text on black background)
> 3-Higher resolution display uses same pixels as lower resolution display, with light text on black background, leaving right side and bottom raster instead of black
> 
> Expected behavior:
> 1-Both displays utilize the resolution (same pixel grid) of the lower resolution display
> 2-Lower resolution display behaves as expected
> 3-Entire higher resolution display's background is black instead of portions in raster
> 
> Workaround: add e.g. video=1440x900@60 to Grub's linu lines, which causes both displays to use the same nominal mode on the full display space.
> 
> Typical other linu line options:
> noresume consoleblank=0 net.ifnames=0 ipv6.disable=1 preempt=full mitigations=none
> 
> My Tesla has HDMI and DVI outputs, tested with 1920x1200 and 1680x1050 displays.
> My Fermi has dual DisplayPort, tested with 2560x1440 and 1680x1050 displays.
> Occurs Tumbleweed with 6.3.2 and 6.2.12 kernel-default, and with 6.2.15 on Fedora 38, and (partially with Tesla, right side only) with 6.2.12 and 6.3.3 on Mageia 9.
> Does not occur with 6.1.12 kernel-default on NVidia, or with AMD Caicos (Terascale2) GPU, or with Intel Eaglelake GPU.
> Tested only on legacy booting (no UEFI support).
> Others might describe what I call "raster" as multicolored snow.

See bugzilla for the full thread and attached dmesg.

Anyway, I'm adding it to regzbot:

#regzbot introduced: v6.1.12..v6.2.12
#regzbot title: vast raster right and bottom borders on larger display (two displays with inequal resolution) unless forcing resolution with video= parameter

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

Re: Fwd: absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers produce vast raster right and bottom borders on the larger resolution of two displays

[Bagas Sanjaya]

On 5/25/23 17:52, Bagas Sanjaya wrote:
> Hi,
> 
> I notice a regression report on Bugzilla [1]. Quoting from it:
> 
>> Original Summary:
>> absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers produce vast raster right and bottom borders on the larger resolution of two displays
>>
>> To reproduce:
>> 1-connect two unequal native resolution displays to a Tesla or Firmi GPU
>> 2-don't have plymouth in use (I don't ever have it installed, so don't know whether it impacts)
>> 3-don't include e.g. video=1440x900@60 directive on Grub's linu lines
>> 4-boot Tumbleweed or Fedora 38
>> 5-switch to a vtty, e.g. Ctrl-Alt-F3
>>
>> Actual behavior:
>> 1-Both displays utilize the resolution (same pixel grid) of the lower resolution display
>> 2-Lower resolution display behaves as expected (light text on black background)
>> 3-Higher resolution display uses same pixels as lower resolution display, with light text on black background, leaving right side and bottom raster instead of black
>>
>> Expected behavior:
>> 1-Both displays utilize the resolution (same pixel grid) of the lower resolution display
>> 2-Lower resolution display behaves as expected
>> 3-Entire higher resolution display's background is black instead of portions in raster
>>
>> Workaround: add e.g. video=1440x900@60 to Grub's linu lines, which causes both displays to use the same nominal mode on the full display space.
>>
>> Typical other linu line options:
>> noresume consoleblank=0 net.ifnames=0 ipv6.disable=1 preempt=full mitigations=none
>>
>> My Tesla has HDMI and DVI outputs, tested with 1920x1200 and 1680x1050 displays.
>> My Fermi has dual DisplayPort, tested with 2560x1440 and 1680x1050 displays.
>> Occurs Tumbleweed with 6.3.2 and 6.2.12 kernel-default, and with 6.2.15 on Fedora 38, and (partially with Tesla, right side only) with 6.2.12 and 6.3.3 on Mageia 9.
>> Does not occur with 6.1.12 kernel-default on NVidia, or with AMD Caicos (Terascale2) GPU, or with Intel Eaglelake GPU.
>> Tested only on legacy booting (no UEFI support).
>> Others might describe what I call "raster" as multicolored snow.
> 
> See bugzilla for the full thread and attached dmesg.
> 
> Anyway, I'm adding it to regzbot:
> 
> #regzbot introduced: v6.1.12..v6.2.12
> #regzbot title: vast raster right and bottom borders on larger display (two displays with inequal resolution) unless forcing resolution with video= parameter
> 

Oops, I forget to add bugzilla link:

#regzbot introduced: v6.1.12..v6.2.12 https://bugzilla.kernel.org/show_bug.cgi?id=217479
#regzbot from: Felix Miata <mrmazda@earthlink.net>

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

Re: [Nouveau] Fwd: absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers produce vast raster right and bottom borders on the larger resolution of two displays

[Thorsten Leemhuis]

On 25.05.23 12:55, Bagas Sanjaya wrote:
> On 5/25/23 17:52, Bagas Sanjaya wrote:
>>
>> I notice a regression report on Bugzilla [1]. Quoting from it:
>> [...]
>> Anyway, I'm adding it to regzbot:
>>
>> #regzbot introduced: v6.1.12..v6.2.12
>> #regzbot title: vast raster right and bottom borders on larger display (two displays with inequal resolution) unless forcing resolution with video= parameter

Bagas, thx again for your efforts, much appreciated. But I guess for drm
drivers that have a line like

B: https://gitlab.freedesktop.org/drm/[...]

in MAINTAINERS (which includes all the popular drm drivers) this just
creates a lot of confusion for everyone, as one issue will likely end up
being discussed in two or three places in parallel (bugzilla,
freedesktop, email). Better tell reporters to move their issue to the
freedesktop drm tracker and close the ticket in bugzilla. And don't get
regzbot involved, as it for now it sadly is unable to monitor the
freedesktop drm tracker (sooner or later I'll fix that, but for now it's
a blind spot :-/).

Pretty sure none of the DRM developers will disagree, but if I'm wrong,
please holler.

> Oops, I forget to add bugzilla link:
> 
> #regzbot introduced: v6.1.12..v6.2.12 https://bugzilla.kernel.org/show_bug.cgi?id=217479
> #regzbot from: Felix Miata <mrmazda@earthlink.net>

Side note: that currently does not work with regzbot. :-/ Whatever, I'll
remove it from the tracking due to above reasons:

#regzbot inconclusive: sadly not tracked for now

Ciao, Thorsten

Re: Fwd: absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers produce vast raster right and bottom borders on the larger resolution of two displays

[Bagas Sanjaya]

On 5/25/23 17:55, Bagas Sanjaya wrote:
> On 5/25/23 17:52, Bagas Sanjaya wrote:
>> Hi,
>>
>> I notice a regression report on Bugzilla [1]. Quoting from it:
>>
>>> Original Summary:
>>> absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers produce vast raster right and bottom borders on the larger resolution of two displays
>>>
>>> To reproduce:
>>> 1-connect two unequal native resolution displays to a Tesla or Firmi GPU
>>> 2-don't have plymouth in use (I don't ever have it installed, so don't know whether it impacts)
>>> 3-don't include e.g. video=1440x900@60 directive on Grub's linu lines
>>> 4-boot Tumbleweed or Fedora 38
>>> 5-switch to a vtty, e.g. Ctrl-Alt-F3
>>>
>>> Actual behavior:
>>> 1-Both displays utilize the resolution (same pixel grid) of the lower resolution display
>>> 2-Lower resolution display behaves as expected (light text on black background)
>>> 3-Higher resolution display uses same pixels as lower resolution display, with light text on black background, leaving right side and bottom raster instead of black
>>>
>>> Expected behavior:
>>> 1-Both displays utilize the resolution (same pixel grid) of the lower resolution display
>>> 2-Lower resolution display behaves as expected
>>> 3-Entire higher resolution display's background is black instead of portions in raster
>>>
>>> Workaround: add e.g. video=1440x900@60 to Grub's linu lines, which causes both displays to use the same nominal mode on the full display space.
>>>
>>> Typical other linu line options:
>>> noresume consoleblank=0 net.ifnames=0 ipv6.disable=1 preempt=full mitigations=none
>>>
>>> My Tesla has HDMI and DVI outputs, tested with 1920x1200 and 1680x1050 displays.
>>> My Fermi has dual DisplayPort, tested with 2560x1440 and 1680x1050 displays.
>>> Occurs Tumbleweed with 6.3.2 and 6.2.12 kernel-default, and with 6.2.15 on Fedora 38, and (partially with Tesla, right side only) with 6.2.12 and 6.3.3 on Mageia 9.
>>> Does not occur with 6.1.12 kernel-default on NVidia, or with AMD Caicos (Terascale2) GPU, or with Intel Eaglelake GPU.
>>> Tested only on legacy booting (no UEFI support).
>>> Others might describe what I call "raster" as multicolored snow.
>>
>> See bugzilla for the full thread and attached dmesg.
>>
>> Anyway, I'm adding it to regzbot:
>>
>> #regzbot introduced: v6.1.12..v6.2.12
>> #regzbot title: vast raster right and bottom borders on larger display (two displays with inequal resolution) unless forcing resolution with video= parameter
>>
> 
> Oops, I forget to add bugzilla link:
> 
> #regzbot introduced: v6.1.12..v6.2.12 https://bugzilla.kernel.org/show_bug.cgi?id=217479
> #regzbot from: Felix Miata <mrmazda@earthlink.net>
> 

Oops, again, I messed up the regzbot entry (reporter field still assigned
to me). Inconclusiving...

#regzbot inconclusive: Wrong reporter assigned (from: doesn't take effect)

Please ignore this thread as I will send a new one with proper regzbot
commands.

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

Re: Fwd: absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers produce vast raster right and bottom borders on the larger resolution of two displays

[Karol Herbst]

[-- Attachment #1: Type: text/plain, Size: 3594 bytes --]

I wouldn't be surprised if 4a16dd9d18a0 is the culprit and that it was
always broken like this with drm fbdev. Anyway, the logs don't indicate we
are actually doing anything wrong, It's just that the tty handling is a
little bonkers as always.

On Thu, May 25, 2023 at 1:37 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:

> On 5/25/23 17:55, Bagas Sanjaya wrote:
> > On 5/25/23 17:52, Bagas Sanjaya wrote:
> >> Hi,
> >>
> >> I notice a regression report on Bugzilla [1]. Quoting from it:
> >>
> >>> Original Summary:
> >>> absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers
> produce vast raster right and bottom borders on the larger resolution of
> two displays
> >>>
> >>> To reproduce:
> >>> 1-connect two unequal native resolution displays to a Tesla or Firmi
> GPU
> >>> 2-don't have plymouth in use (I don't ever have it installed, so don't
> know whether it impacts)
> >>> 3-don't include e.g. video=1440x900@60 directive on Grub's linu lines
> >>> 4-boot Tumbleweed or Fedora 38
> >>> 5-switch to a vtty, e.g. Ctrl-Alt-F3
> >>>
> >>> Actual behavior:
> >>> 1-Both displays utilize the resolution (same pixel grid) of the lower
> resolution display
> >>> 2-Lower resolution display behaves as expected (light text on black
> background)
> >>> 3-Higher resolution display uses same pixels as lower resolution
> display, with light text on black background, leaving right side and bottom
> raster instead of black
> >>>
> >>> Expected behavior:
> >>> 1-Both displays utilize the resolution (same pixel grid) of the lower
> resolution display
> >>> 2-Lower resolution display behaves as expected
> >>> 3-Entire higher resolution display's background is black instead of
> portions in raster
> >>>
> >>> Workaround: add e.g. video=1440x900@60 to Grub's linu lines, which
> causes both displays to use the same nominal mode on the full display space.
> >>>
> >>> Typical other linu line options:
> >>> noresume consoleblank=0 net.ifnames=0 ipv6.disable=1 preempt=full
> mitigations=none
> >>>
> >>> My Tesla has HDMI and DVI outputs, tested with 1920x1200 and 1680x1050
> displays.
> >>> My Fermi has dual DisplayPort, tested with 2560x1440 and 1680x1050
> displays.
> >>> Occurs Tumbleweed with 6.3.2 and 6.2.12 kernel-default, and with
> 6.2.15 on Fedora 38, and (partially with Tesla, right side only) with
> 6.2.12 and 6.3.3 on Mageia 9.
> >>> Does not occur with 6.1.12 kernel-default on NVidia, or with AMD
> Caicos (Terascale2) GPU, or with Intel Eaglelake GPU.
> >>> Tested only on legacy booting (no UEFI support).
> >>> Others might describe what I call "raster" as multicolored snow.
> >>
> >> See bugzilla for the full thread and attached dmesg.
> >>
> >> Anyway, I'm adding it to regzbot:
> >>
> >> #regzbot introduced: v6.1.12..v6.2.12
> >> #regzbot title: vast raster right and bottom borders on larger display
> (two displays with inequal resolution) unless forcing resolution with
> video= parameter
> >>
> >
> > Oops, I forget to add bugzilla link:
> >
> > #regzbot introduced: v6.1.12..v6.2.12
> https://bugzilla.kernel.org/show_bug.cgi?id=217479
> > #regzbot from: Felix Miata <mrmazda@earthlink.net>
> >
>
> Oops, again, I messed up the regzbot entry (reporter field still assigned
> to me). Inconclusiving...
>
> #regzbot inconclusive: Wrong reporter assigned (from: doesn't take effect)
>
> Please ignore this thread as I will send a new one with proper regzbot
> commands.
>
> Thanks.
>
> --
> An old man doll... just what I always wanted! - Clara
>
>

[-- Attachment #2: Type: text/html, Size: 4629 bytes --]

Re: Fwd: absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers produce vast raster right and bottom borders on the larger resolution of two displays

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

On Thu, May 25, 2023 at 06:37:05PM +0700, Bagas Sanjaya wrote:
> Oops, again, I messed up the regzbot entry (reporter field still assigned
> to me). Inconclusiving...
> 
> #regzbot inconclusive: Wrong reporter assigned (from: doesn't take effect)
> 
> Please ignore this thread as I will send a new one with proper regzbot
> commands.

No need to resend this report as Thorsten noted that DRM subsystem already
have gitlab tracker [1].

Sorry for inconvenience.

[1]: https://lore.kernel.org/regressions/d4879ff1-b9ac-0373-ceb2-beaa645fba23@leemhuis.info/

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [Nouveau] Fwd: absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers produce vast raster right and bottom borders on the larger resolution of two displays

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 935 bytes --]

On Thu, May 25, 2023 at 01:24:42PM +0200, Thorsten Leemhuis wrote:
> Bagas, thx again for your efforts, much appreciated. But I guess for drm
> drivers that have a line like
> 
> B: https://gitlab.freedesktop.org/drm/[...]
> 
> in MAINTAINERS (which includes all the popular drm drivers) this just
> creates a lot of confusion for everyone, as one issue will likely end up
> being discussed in two or three places in parallel (bugzilla,
> freedesktop, email). Better tell reporters to move their issue to the
> freedesktop drm tracker and close the ticket in bugzilla. And don't get
> regzbot involved, as it for now it sadly is unable to monitor the
> freedesktop drm tracker (sooner or later I'll fix that, but for now it's
> a blind spot :-/).
> 
> Pretty sure none of the DRM developers will disagree, but if I'm wrong,
> please holler.

OK, thanks!

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]