On Fri, 6 Oct 2023, Sui Jingfeng wrote:
> > I think this makes sense per the spec, but there's always a risk of
> > breaking something, so it's nice if the change actually *fixes*
> > something to make that risk worthwhile.
>
>
> Maciej mentioned that PCI_CLASS_NOT_DEFINED_VGA device should
On Tue, 13 Jun 2023, Sui Jingfeng wrote:
> Deal only with the VGA devcie(pdev->class == 0x0300), so replace the
Typo here: s/devcie/device/.
> pci_get_subsys() function with pci_get_class(). Filter the non-PCI display
> device(pdev->class != 0x0300) out. There no need to process the
Hi Geert,
> > > .> [1]
> > > http://kisskb.ellerman.id.au/kisskb/branch/linus/head/9abf2313adc1ca1b6180c508c25f22f9395cc780/
> > > (all 149 configs)
>
> > > > + {standard input}: Error: branch to a symbol in another ISA mode:
> > > > 1339 =>
> > > > 2616, 2621
> > >
> > >
On Mon, 17 Oct 2022, Geert Uytterhoeven wrote:
> > + {standard input}: Error: branch to a symbol in another ISA mode: 1339 =>
> > 2616, 2621
>
> mips-gcc11/micro32r2_defconfig
> mips-gcc11/micro32r2el_defconfig
Where can these configs be obtained from?
Maciej
nce to use them and second
they do not change the console structure to something possibly different
from what was used by `vc_resize'.
Move the propagation of the vgacon boot parameters ahead of the call to
`vc_resize' then. Adjust the comment accordingly.
Signed-off-by: Maciej W. Rozycki
R
On Sat, 15 May 2021, Maciej W. Rozycki wrote:
> On Sat, 15 May 2021, Tetsuo Handa wrote:
>
> > diff --git a/drivers/video/fbdev/core/fbcon.c
> > b/drivers/video/fbdev/core/fbcon.c
> > index 3406067985b1..22bb3892f6bd 100644
> > --- a/drivers/video/fbdev/core/f
'm currently away from my lab and this
requires physical presence.
Reviewed-by: Maciej W. Rozycki
Maciej
On Fri, 14 May 2021, Linus Torvalds wrote:
> > Overall I think it does make sense to resize the text console at any
> > time, even if the visible console (VT) chosen is in the graphics mode,
>
> It might make sense, but only if we call the function to update the
> low-level data.
>
> Not
On Fri, 14 May 2021, Linus Torvalds wrote:
> > Currently it is impossible to control upper limit of rows/columns values
> > based on amount of memory reserved for the graphical screen, for
> > resize_screen() calls vc->vc_sw->con_resize() only if vc->vc_mode is not
> > already KD_GRAPHICS
>
>
. The proportions change according to text mode geometries chosen.
Revert the change verbatim then, bringing back previous VT resizing.
Signed-off-by: Maciej W. Rozycki
Fixes: 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE")
Cc: sta...@vger.kernel.org # v5.10+
---
No chang
d=32577e96d88447ded2d3b76d71254fb855245837
[2]
https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3
Signed-off-by: Maciej W. Rozycki
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: sta...@vger.kernel.org # v2.6.12+
---
Changes from v1:
- Clarification adde
of the screen. Of course the
proportions change according to text mode geometries and font sizes
chosen.
Address the problem then, by updating the text mode geometry defaults
rather than checking against them whenever the VT is resized via a user
ioctl.
Signed-off-by: Maciej W. Rozycki
Fixes
Hi,
This is a minor update to the previous version of the series, adding a
clarification to 3/3 as to the problem the original fix to which caused
the functional regression the removal of extra VT_RESIZEX parameter
handling caused. No change to actual code.
See individual change
ont_height = clin;
+ vc->vc_font.height = clin;
making the parameter apply to framebuffer devices as well, perhaps due
to the use of "font" in the name of the original `video_font_height'
variable. Use "cell" in the new struct member then to avoid am
. The proportions change according to text mode geometries chosen.
Revert the change verbatim then, bringing back previous VT resizing.
Signed-off-by: Maciej W. Rozycki
Fixes: 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE")
Cc: sta...@vger.kernel.org # v5.10+
---
drivers/tty/vt/
Hi,
I got to the bottom of the issue with VT_RESIZEX recently discussed and
came up with this small patch series, fixing an additional issue that I
originally thought might be broken VGA hardware emulation with my laptop,
which however turned out to be intertwined with the original problem
of the screen. Of course the
proportions change according to text mode geometries and font sizes
chosen.
Address the problem then, by updating the text mode geometry defaults
rather than checking against them whenever the VT is resized via a user
ioctl.
Signed-off-by: Maciej W. Rozycki
Fixes
On Mon, 12 Apr 2021, Daniel Vetter wrote:
> > Note that it's entirely possible that things continue to work well
> > despite this warning. It's unclear to me from your email if you
> > actually see any difference (and apparently you're not able to see it
> > right now due to not being close to
On Tue, 29 Sep 2020, Greg KH wrote:
> > > > >> VT_RESIZEX was introduced in Linux 1.3.3, but it is unclear that what
> > > > >> comes to the "+ more" part, and I couldn't find a user of VT_RESIZEX.
> > > > >>
> > > > >
> > > > > It seems this is/was used by "svgatextmode" which seems to be at
>
19 matches
Mail list logo
