On a 2014 DELL computer I installed Debian a few months ago. I once used
a VGA connection to an older Haier LED TV, which gave me 1920x1080 on
both X (MATE) and the TTY. Because VGA doesn't support audio and I had an
HDMI cable handy I used that instead. I had to fall back to 1280x1024
(ugly aspect ratio) because that is the highest the TV supports on
HDMI. I set 1280x1024 up for X, but when I switch to a TTY the TV goes to
1920x1080 (it reports "1080p" in a popup) and much of the content
vanishes.

I tried to use fbset to somehow force the TV to accept 1280x1024 for TTY,
but no luck. I used 640x480 because I am sure the GPU will support
this. If it works I would try higher resolutions.

Among other things I tried (not right after the other)

fbset -fb /dev/fb0 640x480-60
fbset -a -fb /dev/fb1 640x480-60 (resulting in "No such file...)
fbset -xres 640 -yres 480 -match
fbset -bcast true -fb /dev/fb0 640x480-60

so a wild trial and error, probing some of the suggestions Google came up
with. None did anything (some printed error message though).

fbset --show

always outputs

mode "1920x1080"
geometry 1920 1080 1920 1080 32
timings 0 0 0 0 0 0 0
accel true
rgba 8/16,8/8,8/0,0/0
endmode

I assume fbset is the right command, but it needs some special parameter
to convince the TV to accept a lower resolution than 1920x1080. But which?
--
Andreas

https://news-commentaries.blogspot.com/

Andreas Kohlbach <ank@spamfence.net> wrote:
> On a 2014 DELL computer I installed Debian a few months ago. I once used
> a VGA connection to an older Haier LED TV, which gave me 1920x1080 on
> both X (MATE) and the TTY. Because VGA doesn't support audio and I had an
> HDMI cable handy I used that instead. I had to fall back to 1280x1024
> (ugly aspect ratio) because that is the highest the TV supports on
> HDMI. I set 1280x1024 up for X, but when I switch to a TTY the TV goes to
> 1920x1080 (it reports "1080p" in a popup) and much of the content
> vanishes.
>
> I tried to use fbset to somehow force the TV to accept 1280x1024 for TTY,
> but no luck.

Not sure if you're likely to have any better luck,
but have you maybe tried xrandr instead?

> I used 640x480 because I am sure the GPU will support
> this. If it works I would try higher resolutions.
>
> Among other things I tried (not right after the other)
>
> fbset -fb /dev/fb0 640x480-60
> fbset -a -fb /dev/fb1 640x480-60 (resulting in "No such file...)
> fbset -xres 640 -yres 480 -match
> fbset -bcast true -fb /dev/fb0 640x480-60
>
> so a wild trial and error, probing some of the suggestions Google came up
> with. None did anything (some printed error message though).
>
> fbset --show
>
> always outputs
>
> mode "1920x1080"
> geometry 1920 1080 1920 1080 32
> timings 0 0 0 0 0 0 0
> accel true
> rgba 8/16,8/8,8/0,0/0
> endmode
>
> I assume fbset is the right command, but it needs some special parameter
> to convince the TV to accept a lower resolution than 1920x1080. But which?

--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

On Sat, 16 Apr 2022 04:51:34 -0000 (UTC), John Forkosh wrote:
>
> Andreas Kohlbach <ank@spamfence.net> wrote:
>> On a 2014 DELL computer I installed Debian a few months ago. I once used
>> a VGA connection to an older Haier LED TV, which gave me 1920x1080 on
>> both X (MATE) and the TTY. Because VGA doesn't support audio and I had an
>> HDMI cable handy I used that instead. I had to fall back to 1280x1024
>> (ugly aspect ratio) because that is the highest the TV supports on
>> HDMI. I set 1280x1024 up for X, but when I switch to a TTY the TV goes to
>> 1920x1080 (it reports "1080p" in a popup) and much of the content
>> vanishes.
>>
>> I tried to use fbset to somehow force the TV to accept 1280x1024 for TTY,
>> but no luck.
>
> Not sure if you're likely to have any better luck,
> but have you maybe tried xrandr instead?

xrandr is for X only. It works there, but I need to find a solution for
the TTYs. fbset is supposed to deliver this. If I only knew what
parameters it needs.
--
Andreas

Andreas Kohlbach <ank@spamfence.net> wrote:
> On Sat, 16 Apr 2022 04:51:34 -0000 (UTC), John Forkosh wrote:
>>
>> Andreas Kohlbach <ank@spamfence.net> wrote:
>>> On a 2014 DELL computer I installed Debian a few months ago. I once used
>>> a VGA connection to an older Haier LED TV, which gave me 1920x1080 on
>>> both X (MATE) and the TTY. Because VGA doesn't support audio and I had an
>>> HDMI cable handy I used that instead. I had to fall back to 1280x1024
>>> (ugly aspect ratio) because that is the highest the TV supports on
>>> HDMI. I set 1280x1024 up for X, but when I switch to a TTY the TV goes to
>>> 1920x1080 (it reports "1080p" in a popup) and much of the content
>>> vanishes.
>>>
>>> I tried to use fbset to somehow force the TV to accept 1280x1024 for TTY,
>>> but no luck.
>>
>> Not sure if you're likely to have any better luck,
>> but have you maybe tried xrandr instead?
>
> xrandr is for X only. It works there, but I need to find a solution for
> the TTYs. fbset is supposed to deliver this. If I only knew what
> parameters it needs.

I'm not sure about fbset, but if you're using the VESA video driver
you can use the vga= boot code:
https://www.kernel.org/doc/html/latest/admin-guide/svga.html
https://www.kernel.org/doc/html/latest/fb/vesafb.html

Other framebuffer drivers such as this one have their own boot
code:
https://www.kernel.org/doc/html/latest/fb/ep93xx-fb.html#setting-the-video-mode

You don't say which framebuffer driver module you are using, but
you might find more info on it here after identifying it in the
output of lsmod:
https://www.kernel.org/doc/html/latest/fb/index.html

--
__ __
#_ < |\| |< _#

On 17 Apr 2022 09:02:32 +1000, Computer Nerd Kev wrote:
>
> Andreas Kohlbach <ank@spamfence.net> wrote:
>> On Sat, 16 Apr 2022 04:51:34 -0000 (UTC), John Forkosh wrote:
>>>
>>> Andreas Kohlbach <ank@spamfence.net> wrote:
>>>> On a 2014 DELL computer I installed Debian a few months ago. I once used
>>>> a VGA connection to an older Haier LED TV, which gave me 1920x1080 on
>>>> both X (MATE) and the TTY. Because VGA doesn't support audio and I had an
>>>> HDMI cable handy I used that instead. I had to fall back to 1280x1024
>>>> (ugly aspect ratio) because that is the highest the TV supports on
>>>> HDMI. I set 1280x1024 up for X, but when I switch to a TTY the TV goes to
>>>> 1920x1080 (it reports "1080p" in a popup) and much of the content
>>>> vanishes.
>>>>
>>>> I tried to use fbset to somehow force the TV to accept 1280x1024 for TTY,
>>>> but no luck.
>>>
>>> Not sure if you're likely to have any better luck,
>>> but have you maybe tried xrandr instead?
>>
>> xrandr is for X only. It works there, but I need to find a solution for
>> the TTYs. fbset is supposed to deliver this. If I only knew what
>> parameters it needs.
>
> I'm not sure about fbset, but if you're using the VESA video driver
> you can use the vga= boot code:
> https://www.kernel.org/doc/html/latest/admin-guide/svga.html
> https://www.kernel.org/doc/html/latest/fb/vesafb.html

Is this still valid? Pages carry a copyright of 1999.

> Other framebuffer drivers such as this one have their own boot
> code:
> https://www.kernel.org/doc/html/latest/fb/ep93xx-fb.html#setting-the-video-mode
>
> You don't say which framebuffer driver module you are using, but
> you might find more info on it here after identifying it in the
> output of lsmod:
> https://www.kernel.org/doc/html/latest/fb/index.html

I only have /dev/fb0.

Odd thing I forgot to mention. When I boot and go into the computer's
BIOS setup it's also messed up. Again the TV reports 1920x1080 and only a
part of the BIOS page is visible.

Makes me now think it has noting to do with the framebuffer (or fbset).

Already set the TB back to factory settings, but it again switches to
1920x1080.

So abstract: Can I tell Linux somehow to force the TV using a certain
resolution on the TTY? Again, on X that works. Just not on the TTYs.
--
Andreas

Andreas Kohlbach <ank@spamfence.net> wrote:
> On 17 Apr 2022 09:02:32 +1000, Computer Nerd Kev wrote:
>> Andreas Kohlbach <ank@spamfence.net> wrote:
>>>
>>> xrandr is for X only. It works there, but I need to find a solution for
>>> the TTYs. fbset is supposed to deliver this. If I only knew what
>>> parameters it needs.
>>
>> I'm not sure about fbset, but if you're using the VESA video driver
>> you can use the vga= boot code:
>> https://www.kernel.org/doc/html/latest/admin-guide/svga.html
>> https://www.kernel.org/doc/html/latest/fb/vesafb.html
>
> Is this still valid? Pages carry a copyright of 1999.

It's supposed to apply to the latest kernel release, so in theory
yes. I use the vga= boot code on systems running current kernel
versions myself, so it definately still works for the VESA driver.
I haven't tried any equivalent codes for the chipset-specific
framebuffer drivers, so far as I can remember.

>> Other framebuffer drivers such as this one have their own boot
>> code:
>> https://www.kernel.org/doc/html/latest/fb/ep93xx-fb.html#setting-the-video-mode
>>
>> You don't say which framebuffer driver module you are using, but
>> you might find more info on it here after identifying it in the
>> output of lsmod:
>> https://www.kernel.org/doc/html/latest/fb/index.html
>
> I only have /dev/fb0.

Well yeah, that's the interface to a framebuffer driver module. The
question is: which driver module is it? If there's no
graphics-chipset-specific one visible in lsmod, then you're likely
using the VESA driver (maybe there's a more direct way to determine
this, I'm not sure), so try the vga= boot code on the boot command
line.

> Odd thing I forgot to mention. When I boot and go into the computer's
> BIOS setup it's also messed up. Again the TV reports 1920x1080 and only a
> part of the BIOS page is visible.
>
> Makes me now think it has noting to do with the framebuffer (or fbset).

I think it's still the framebuffer settings.

--
__ __
#_ < |\| |< _#

On 17 Apr 2022 18:27:56 +1000, Computer Nerd Kev wrote:
>
> Andreas Kohlbach <ank@spamfence.net> wrote:
>> On 17 Apr 2022 09:02:32 +1000, Computer Nerd Kev wrote:
>>> Andreas Kohlbach <ank@spamfence.net> wrote:
>>>>
>>>> xrandr is for X only. It works there, but I need to find a solution for
>>>> the TTYs. fbset is supposed to deliver this. If I only knew what
>>>> parameters it needs.
>>>
>>> I'm not sure about fbset, but if you're using the VESA video driver
>>> you can use the vga= boot code:
>>> https://www.kernel.org/doc/html/latest/admin-guide/svga.html
>>> https://www.kernel.org/doc/html/latest/fb/vesafb.html
>>
>> Is this still valid? Pages carry a copyright of 1999.
>
> It's supposed to apply to the latest kernel release, so in theory
> yes. I use the vga= boot code on systems running current kernel
> versions myself, so it definately still works for the VESA driver.
> I haven't tried any equivalent codes for the chipset-specific
> framebuffer drivers, so far as I can remember.

I remember having used vga=792 or something back in the day when this was
new and exciting. Today I'd rather skip framebuffer altogether and have a
plain 25 line "real" text console.

For that I also tried "nomodeset". That almost did it for the TTY. But
switching to X the maximal possible resolution was 640x480 or thereabout.

>>> Other framebuffer drivers such as this one have their own boot
>>> code:
>>> https://www.kernel.org/doc/html/latest/fb/ep93xx-fb.html#setting-the-video-mode
>>>
>>> You don't say which framebuffer driver module you are using, but
>>> you might find more info on it here after identifying it in the
>>> output of lsmod:
>>> https://www.kernel.org/doc/html/latest/fb/index.html
>>
>> I only have /dev/fb0.
>
> Well yeah, that's the interface to a framebuffer driver module. The
> question is: which driver module is it? If there's no
> graphics-chipset-specific one visible in lsmod, then you're likely
> using the VESA driver (maybe there's a more direct way to determine
> this, I'm not sure), so try the vga= boot code on the boot command
> line.

For lsmod, what exactly am I looking for?

>> Odd thing I forgot to mention. When I boot and go into the computer's
>> BIOS setup it's also messed up. Again the TV reports 1920x1080 and only a
>> part of the BIOS page is visible.
>>
>> Makes me now think it has noting to do with the framebuffer (or fbset).
>
> I think it's still the framebuffer settings.

Would be nice to completely disable framebuffer, if I knew how.
--
Andreas

I didn't see how much text is missing for you. If it is a bit
on the outside, then maybe you just have to adjust the p-mode
on the TV. Try switching between the various p-modes and see
if you get the entire image in one of them. I had a similar
problem when I was plugging an rpi running mate into my LED
TV.

Cheers,
Rob Komar

Andreas Kohlbach <ank@spamfence.net> wrote:
> On 17 Apr 2022 18:27:56 +1000, Computer Nerd Kev wrote:
>> Andreas Kohlbach <ank@spamfence.net> wrote:
>>> On 17 Apr 2022 09:02:32 +1000, Computer Nerd Kev wrote:
>>>>
>>>> I'm not sure about fbset, but if you're using the VESA video driver
>>>> you can use the vga= boot code:
>>>> https://www.kernel.org/doc/html/latest/admin-guide/svga.html
>>>> https://www.kernel.org/doc/html/latest/fb/vesafb.html
>>>
>>> Is this still valid? Pages carry a copyright of 1999.
>>
>> It's supposed to apply to the latest kernel release, so in theory
>> yes. I use the vga= boot code on systems running current kernel
>> versions myself, so it definately still works for the VESA driver.
>> I haven't tried any equivalent codes for the chipset-specific
>> framebuffer drivers, so far as I can remember.
>
> I remember having used vga=792 or something back in the day when this was
> new and exciting. Today I'd rather skip framebuffer altogether and have a
> plain 25 line "real" text console.
>
> For that I also tried "nomodeset". That almost did it for the TTY. But
> switching to X the maximal possible resolution was 640x480 or thereabout.

Odd, are you using graphics-chipset-specific driver for X?

>>>> Other framebuffer drivers such as this one have their own boot
>>>> code:
>>>> https://www.kernel.org/doc/html/latest/fb/ep93xx-fb.html#setting-the-video-mode
>>>>
>>>> You don't say which framebuffer driver module you are using, but
>>>> you might find more info on it here after identifying it in the
>>>> output of lsmod:
>>>> https://www.kernel.org/doc/html/latest/fb/index.html
>>>
>>> I only have /dev/fb0.
>>
>> Well yeah, that's the interface to a framebuffer driver module. The
>> question is: which driver module is it? If there's no
>> graphics-chipset-specific one visible in lsmod, then you're likely
>> using the VESA driver (maybe there's a more direct way to determine
>> this, I'm not sure), so try the vga= boot code on the boot command
>> line.
>
> For lsmod, what exactly am I looking for?

It's easiest to work out your graphics chipset (eg. look at the
"VGA compatible controller" line in the output os lspci), then look
up which framebuffer driver would be loaded for it if not using
the VESA driver. I think their names all end with "fb" though.

Reading a little more through the docs I posted before I see that
it's stated explicitly that you need a graphics-chipset-specific
framebuffer driver to be able to dynamically change the video mode:

"For x86 systems, they almost universally have VGA cards, so vga16fb
and vesafb will always be available. However, using a
chipset-specific driver will give you more speed and features, such
as the ability to change the video mode dynamically."
https://www.kernel.org/doc/html/latest/fb/fbcon.html

So I'm guessing that you're not using a graphics-chipset-specific
framebuffer driver, and that's why your fbset commands didn't work.
You need to use the vga= boot code (for the VESA driver at least).

--
__ __
#_ < |\| |< _#

On Mon, 18 Apr 2022 12:47:05 -0400, Robert Komar wrote:
>
> I didn't see how much text is missing for you. If it is a bit
> on the outside, then maybe you just have to adjust the p-mode
> on the TV. Try switching between the various p-modes and see
> if you get the entire image in one of them. I had a similar
> problem when I was plugging an rpi running mate into my LED
> TV.

From the normal 80 characters about 10 are missing on either side. Also on
top and bottom.
--
Andreas

On 19 Apr 2022 08:45:28 +1000, Computer Nerd Kev wrote:
>
> Andreas Kohlbach <ank@spamfence.net> wrote:
>> On 17 Apr 2022 18:27:56 +1000, Computer Nerd Kev wrote:
>
>>> It's supposed to apply to the latest kernel release, so in theory
>>> yes. I use the vga= boot code on systems running current kernel
>>> versions myself, so it definately still works for the VESA driver.
>>> I haven't tried any equivalent codes for the chipset-specific
>>> framebuffer drivers, so far as I can remember.
>>
>> I remember having used vga=792 or something back in the day when this was
>> new and exciting. Today I'd rather skip framebuffer altogether and have a
>> plain 25 line "real" text console.
>>
>> For that I also tried "nomodeset". That almost did it for the TTY. But
>> switching to X the maximal possible resolution was 640x480 or thereabout.
>
> Odd, are you using graphics-chipset-specific driver for X?

lspci reports

| Intel Corporation 4th Generation Core Processor Family Integrated
| Graphics Controller

>>>>> Other framebuffer drivers such as this one have their own boot
>>>>> code:
>>>>> https://www.kernel.org/doc/html/latest/fb/ep93xx-fb.html#setting-the-video-mode
>>>>>
>>>>> You don't say which framebuffer driver module you are using, but
>>>>> you might find more info on it here after identifying it in the
>>>>> output of lsmod:
>>>>> https://www.kernel.org/doc/html/latest/fb/index.html
>>>>
>>>> I only have /dev/fb0.
>>>
>>> Well yeah, that's the interface to a framebuffer driver module. The
>>> question is: which driver module is it? If there's no
>>> graphics-chipset-specific one visible in lsmod, then you're likely
>>> using the VESA driver (maybe there's a more direct way to determine
>>> this, I'm not sure), so try the vga= boot code on the boot command
>>> line.
>>
>> For lsmod, what exactly am I looking for?
>
> It's easiest to work out your graphics chipset (eg. look at the
> "VGA compatible controller" line in the output os lspci), then look
> up which framebuffer driver would be loaded for it if not using
> the VESA driver. I think their names all end with "fb" though.

lsmod | grep -i fb

doesn't return anything. Same for "vesa".

> Reading a little more through the docs I posted before I see that
> it's stated explicitly that you need a graphics-chipset-specific
> framebuffer driver to be able to dynamically change the video mode:
>
> "For x86 systems, they almost universally have VGA cards, so vga16fb
> and vesafb will always be available. However, using a
> chipset-specific driver will give you more speed and features, such
> as the ability to change the video mode dynamically."
> https://www.kernel.org/doc/html/latest/fb/fbcon.html
>
> So I'm guessing that you're not using a graphics-chipset-specific
> framebuffer driver, and that's why your fbset commands didn't work.
> You need to use the vga= boot code (for the VESA driver at least).

I'll try that on next boot, thanks.
--
Andreas

Andreas Kohlbach <ank@spamfence.net> wrote:
> On 19 Apr 2022 08:45:28 +1000, Computer Nerd Kev wrote:
>>
>> Andreas Kohlbach <ank@spamfence.net> wrote:
>>> On 17 Apr 2022 18:27:56 +1000, Computer Nerd Kev wrote:
>>
>>>> It's supposed to apply to the latest kernel release, so in theory
>>>> yes. I use the vga= boot code on systems running current kernel
>>>> versions myself, so it definately still works for the VESA driver.
>>>> I haven't tried any equivalent codes for the chipset-specific
>>>> framebuffer drivers, so far as I can remember.
>>>
>>> I remember having used vga=792 or something back in the day when this was
>>> new and exciting. Today I'd rather skip framebuffer altogether and have a
>>> plain 25 line "real" text console.
>>>
>>> For that I also tried "nomodeset". That almost did it for the TTY. But
>>> switching to X the maximal possible resolution was 640x480 or thereabout.
>>
>> Odd, are you using graphics-chipset-specific driver for X?
>
> lspci reports
>
> | Intel Corporation 4th Generation Core Processor Family Integrated
> | Graphics Controller

That makes it one of the "Intel HD Graphics" GPUs, but actually
there doesn't seem to be a framebuffer driver for them. The Intel
drivers all seem to be for earlier GPU models. The kernel sources
serve as a full list:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/video/fbdev

>>>>>> Other framebuffer drivers such as this one have their own boot
>>>>>> code:
>>>>>> https://www.kernel.org/doc/html/latest/fb/ep93xx-fb.html#setting-the-video-mode
>>>>>>
>>>>>> You don't say which framebuffer driver module you are using, but
>>>>>> you might find more info on it here after identifying it in the
>>>>>> output of lsmod:
>>>>>> https://www.kernel.org/doc/html/latest/fb/index.html
>>>>>
>>>>> I only have /dev/fb0.
>>>>
>>>> Well yeah, that's the interface to a framebuffer driver module. The
>>>> question is: which driver module is it? If there's no
>>>> graphics-chipset-specific one visible in lsmod, then you're likely
>>>> using the VESA driver (maybe there's a more direct way to determine
>>>> this, I'm not sure), so try the vga= boot code on the boot command
>>>> line.
>>>
>>> For lsmod, what exactly am I looking for?
>>
>> It's easiest to work out your graphics chipset (eg. look at the
>> "VGA compatible controller" line in the output os lspci), then look
>> up which framebuffer driver would be loaded for it if not using
>> the VESA driver. I think their names all end with "fb" though.
>
> lsmod | grep -i fb
>
> doesn't return anything.

Stands to reason, given the above.

> Same for "vesa".

Though it doesn't have to be, I believe the VESA framebuffer driver
is built into most Linux kernels targeted at PCs (I know it is for
the Debian kernel at least). As it's not a separate module, it
won't show in lsmod even if the driver is being used.

>> Reading a little more through the docs I posted before I see that
>> it's stated explicitly that you need a graphics-chipset-specific
>> framebuffer driver to be able to dynamically change the video mode:
>>
>> "For x86 systems, they almost universally have VGA cards, so vga16fb
>> and vesafb will always be available. However, using a
>> chipset-specific driver will give you more speed and features, such
>> as the ability to change the video mode dynamically."
>> https://www.kernel.org/doc/html/latest/fb/fbcon.html
>>
>> So I'm guessing that you're not using a graphics-chipset-specific
>> framebuffer driver, and that's why your fbset commands didn't work.
>> You need to use the vga= boot code (for the VESA driver at least).
>
> I'll try that on next boot, thanks.

If you try vga=ask, it should list modes that may be available and
you can select which one you want to try (some might not work). As
noted before, the docs are here:
https://www.kernel.org/doc/html/latest/fb/vesafb.html

--
__ __
#_ < |\| |< _#

On 19 Apr 2022 12:08:15 +1000, Computer Nerd Kev wrote:
>
> Andreas Kohlbach <ank@spamfence.net> wrote:
>> On 19 Apr 2022 08:45:28 +1000, Computer Nerd Kev wrote:
>>>
>>> Odd, are you using graphics-chipset-specific driver for X?
>>
>> lspci reports
>>
>> | Intel Corporation 4th Generation Core Processor Family Integrated
>> | Graphics Controller
>
> That makes it one of the "Intel HD Graphics" GPUs, but actually
> there doesn't seem to be a framebuffer driver for them. The Intel
> drivers all seem to be for earlier GPU models. The kernel sources
> serve as a full list:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/video/fbdev

That's good. I mean I don't want framebuffer or VESA if possible. But
then it's bad for trouble shooting I guess.

>>> So I'm guessing that you're not using a graphics-chipset-specific
>>> framebuffer driver, and that's why your fbset commands didn't work.
>>> You need to use the vga= boot code (for the VESA driver at least).
>>
>> I'll try that on next boot, thanks.
>
> If you try vga=ask, it should list modes that may be available and
> you can select which one you want to try (some might not work). As
> noted before, the docs are here:
> https://www.kernel.org/doc/html/latest/fb/vesafb.html

I'll use "ask". But on next boot (whenever that will be - probably on a
power outage) I'll try

GRUB_CMDLINE_LINUX_DEFAULT="gfxmode=640x480"

someone recommended first.

Still I believe it's somewhere outside of Linux, because the PC also
isn't able to display the BIOS setup properly. Oddly even after I did a
factory reset (I assume - TV did not give feedback) on the TV it still
starts with the high resolution...
--
Andreas

Andreas Kohlbach <ank@spamfence.net> wrote:
> On Mon, 18 Apr 2022 12:47:05 -0400, Robert Komar wrote:
>>
>> I didn't see how much text is missing for you. If it is a bit
>> on the outside, then maybe you just have to adjust the p-mode
>> on the TV. Try switching between the various p-modes and see
>> if you get the entire image in one of them. I had a similar
>> problem when I was plugging an rpi running mate into my LED
>> TV.
>
> From the normal 80 characters about 10 are missing on either side. Also on
> top and bottom.

That sounds like normal TV "overscan"
(https://en.wikipedia.org/wiki/Overscan) which is a leftover from the
CRT days of television but got taken up by "LCD TV sets" for
"compatibility" reasons.

Does the TV have a "computer" setting in its setup menus (or a
"computer" input). What that setting, or that input, usually really
means is: "don't simulate CRT overscan".

On Tue, 19 Apr 2022 16:04:09 -0000 (UTC), Rich wrote:
>
> Andreas Kohlbach <ank@spamfence.net> wrote:
>> On Mon, 18 Apr 2022 12:47:05 -0400, Robert Komar wrote:
>>>
>>> I didn't see how much text is missing for you. If it is a bit
>>> on the outside, then maybe you just have to adjust the p-mode
>>> on the TV. Try switching between the various p-modes and see
>>> if you get the entire image in one of them. I had a similar
>>> problem when I was plugging an rpi running mate into my LED
>>> TV.
>>
>> From the normal 80 characters about 10 are missing on either side. Also on
>> top and bottom.
>
> That sounds like normal TV "overscan"
> (https://en.wikipedia.org/wiki/Overscan) which is a leftover from the
> CRT days of television but got taken up by "LCD TV sets" for
> "compatibility" reasons.

I don't think it's overscan, because when I tell Linux in X to use
1920x1080 the TV (connected via HDMI) goes to 1024x1280 (because it
cannot 1920x1080) and the result is similar to what I see on a TTY (parts
of the screen "vanished" on all four sides.

If I use a VGA cable ten the TV can 1920x1080 in X and TTY. But I want to
use HDMI.

> Does the TV have a "computer" setting in its setup menus (or a
> "computer" input). What that setting, or that input, usually really
> means is: "don't simulate CRT overscan".

Not that I could find.
--
Andreas

Le 16/04/2022 à 02:22, Andreas Kohlbach a écrit :
> On a 2014 DELL computer I installed Debian a few months ago. I once used
> a VGA connection to an older Haier LED TV, which gave me 1920x1080 on
> both X (MATE) and the TTY. Because VGA doesn't support audio and I had an
> HDMI cable handy I used that instead. I had to fall back to 1280x1024
> (ugly aspect ratio) because that is the highest the TV supports on
> HDMI. I set 1280x1024 up for X, but when I switch to a TTY the TV goes to
> 1920x1080 (it reports "1080p" in a popup) and much of the content
> vanishes.

Looks like the HDMI input of that TV is broken. Maybe bad EDID.
Did you try with another computer or HDMI source ?

You can try to force alternate EDID with the following kernel parameter:

drm.edid_firmware= (drm_kms_helper.edid_firmware for older kernels)

Possible values include edid/1280x1024.bin, edid/1680x1050.bin, or
edid/1920x1080.bin. See kernel-parameters in the kernel documentation
for details.

On Thu, 21 Apr 2022 07:25:32 +0200, Pascal Hambourg wrote:
>
> Le 16/04/2022 à 02:22, Andreas Kohlbach a écrit :
>> On a 2014 DELL computer I installed Debian a few months ago. I once used
>> a VGA connection to an older Haier LED TV, which gave me 1920x1080 on
>> both X (MATE) and the TTY. Because VGA doesn't support audio and I had an
>> HDMI cable handy I used that instead. I had to fall back to 1280x1024
>> (ugly aspect ratio) because that is the highest the TV supports on
>> HDMI. I set 1280x1024 up for X, but when I switch to a TTY the TV goes to
>> 1920x1080 (it reports "1080p" in a popup) and much of the content
>> vanishes.
>
> Looks like the HDMI input of that TV is broken. Maybe bad EDID.
> Did you try with another computer or HDMI source ?

I tried the "HDMI2" now,no change. Have no other computer to test it. But
I have a USB stick with a Debian installer on I might try.

> You can try to force alternate EDID with the following kernel parameter:
>
> drm.edid_firmware= (drm_kms_helper.edid_firmware for older kernels)

> Possible values include edid/1280x1024.bin, edid/1680x1050.bin, or
> edid/1920x1080.bin. See kernel-parameters in the kernel documentation
> for details.

Something like

GRUB_CMDLINE_LINUX_DEFAULT="edid/640x480.bin"

?

I want to be sure, because if this prevents Linux from booting I'll have a
hard time navigating in a grub menu which is only partially displaying.
--
Andreas

Le 22/04/2022 à 18:58, Andreas Kohlbach a écrit :
> On Thu, 21 Apr 2022 07:25:32 +0200, Pascal Hambourg wrote:
>>
>> Le 16/04/2022 à 02:22, Andreas Kohlbach a écrit :
>>> On a 2014 DELL computer I installed Debian a few months ago. I once used
>>> a VGA connection to an older Haier LED TV, which gave me 1920x1080 on
>>> both X (MATE) and the TTY. Because VGA doesn't support audio and I had an
>>> HDMI cable handy I used that instead. I had to fall back to 1280x1024
>>> (ugly aspect ratio) because that is the highest the TV supports on
>>> HDMI. I set 1280x1024 up for X, but when I switch to a TTY the TV goes to
>>> 1920x1080 (it reports "1080p" in a popup) and much of the content
>>> vanishes.
>>
>> Looks like the HDMI input of that TV is broken. Maybe bad EDID.
>> Did you try with another computer or HDMI source ?
>
> I tried the "HDMI2" now,no change. Have no other computer to test it. But
> I have a USB stick with a Debian installer on I might try.

The Debian installer uses "generic" graphic drivers with low resolution
such as 800x600. I do not think this is what you want.

>> You can try to force alternate EDID with the following kernel parameter:
>>
>> drm.edid_firmware= (drm_kms_helper.edid_firmware for older kernels)
>
>> Possible values include edid/1280x1024.bin, edid/1680x1050.bin, or
>> edid/1920x1080.bin. See kernel-parameters in the kernel documentation
>> for details.
>
> Something like
>
> GRUB_CMDLINE_LINUX_DEFAULT="edid/640x480.bin"

More like

drm.edid_firmware=edid/640x480.bin

(but do you really want such a low resolution ?)

> I want to be sure, because if this prevents Linux from booting I'll have a
> hard time navigating in a grub menu which is only partially displaying.

You did not mention that the problem happened also in the GRUB menu.
If you know that 1024x768 (or some other standard resolution) works on
the HDMI input, you could force it in the GRUB menu by setting
GRUB_GFXMODE=1024x768 in /etc/default/grub.

Then, if you have a correct display in the GRUB menu, you can easily
edit the menu entry and add the parameter to the kernel command line
instead of adding it to GRUB_CMDLINE_LINUX_DEFAULT.

On Fri, 22 Apr 2022 20:17:19 +0200, Pascal Hambourg wrote:
>
> Le 22/04/2022 à 18:58, Andreas Kohlbach a écrit :
>> On Thu, 21 Apr 2022 07:25:32 +0200, Pascal Hambourg wrote:
>>>
>>> Le 16/04/2022 à 02:22, Andreas Kohlbach a écrit :
>>>> On a 2014 DELL computer I installed Debian a few months ago. I once used
>>>> a VGA connection to an older Haier LED TV, which gave me 1920x1080 on
>>>> both X (MATE) and the TTY. Because VGA doesn't support audio and I had an
>>>> HDMI cable handy I used that instead. I had to fall back to 1280x1024
>>>> (ugly aspect ratio) because that is the highest the TV supports on
>>>> HDMI. I set 1280x1024 up for X, but when I switch to a TTY the TV goes to
>>>> 1920x1080 (it reports "1080p" in a popup) and much of the content
>>>> vanishes.
>>>
>>> Looks like the HDMI input of that TV is broken. Maybe bad EDID.
>>> Did you try with another computer or HDMI source ?
>> I tried the "HDMI2" now,no change. Have no other computer to test
>> it. But
>> I have a USB stick with a Debian installer on I might try.
>
> The Debian installer uses "generic" graphic drivers with low
> resolution such as 800x600. I do not think this is what you want.

No, but I could see if when switching to a TTY then if the TV again acts up.

>>> You can try to force alternate EDID with the following kernel parameter:
>>>
>>> drm.edid_firmware= (drm_kms_helper.edid_firmware for older kernels)
>>
>>> Possible values include edid/1280x1024.bin, edid/1680x1050.bin, or
>>> edid/1920x1080.bin. See kernel-parameters in the kernel documentation
>>> for details.
>> Something like
>> GRUB_CMDLINE_LINUX_DEFAULT="edid/640x480.bin"
>
> More like
>
> drm.edid_firmware=edid/640x480.bin
>
> (but do you really want such a low resolution ?)

Only for the TTY.

Actually I would like to have the old 80x25 text mode back we had in the
90s before the fancy framebuffer came along. That should be possible (but
how?), because the first boot messages appear to be in "plain text",
before it switches to a higher resolution.

Btw. X works fine already. Don't want changes there.

>> I want to be sure, because if this prevents Linux from booting I'll have a
>> hard time navigating in a grub menu which is only partially displaying.
>
> You did not mention that the problem happened also in the GRUB menu.

I assume it will happen (didn't reboot yet). As it also happens when I
call the computer's BIOS.

> If you know that 1024x768 (or some other standard resolution) works on
> the HDMI input, you could force it in the GRUB menu by setting
> GRUB_GFXMODE=1024x768 in /etc/default/grub.
>
> Then, if you have a correct display in the GRUB menu, you can easily
> edit the menu entry and add the parameter to the kernel command line
> instead of adding it to GRUB_CMDLINE_LINUX_DEFAULT.

Okay, will on next boot (just updated rub with that)
drm.edid_firmware=edid/640x480.bin and if this fails GRUB_GFXMODE=1024x768.
--
Andreas

Le 23/04/2022 à 03:09, Andreas Kohlbach a écrit :
> On Fri, 22 Apr 2022 20:17:19 +0200, Pascal Hambourg wrote:
>>
>> Le 22/04/2022 à 18:58, Andreas Kohlbach a écrit :
>>> On Thu, 21 Apr 2022 07:25:32 +0200, Pascal Hambourg wrote:
>>>>
>>>> Le 16/04/2022 à 02:22, Andreas Kohlbach a écrit :
>>>>> I set 1280x1024 up for X, but when I switch to a TTY the TV goes to
>>>>> 1920x1080 (it reports "1080p" in a popup) and much of the content
>>>>> vanishes.
(...)
>>>> You can try to force alternate EDID with the following kernel parameter:
>>>>
>>>> drm.edid_firmware= (drm_kms_helper.edid_firmware for older kernels)
>>>
>>>> Possible values include edid/1280x1024.bin, edid/1680x1050.bin, or
>>>> edid/1920x1080.bin. See kernel-parameters in the kernel documentation
>>>> for details.
>>> Something like
>>> GRUB_CMDLINE_LINUX_DEFAULT="edid/640x480.bin"
>>
>> More like
>>
>> drm.edid_firmware=edid/640x480.bin

My bad, 640x480 is not supported. Lowest supported resolution is
800x600. I suggest trying 1920x1080 then 1680x1050 which has almost the
same aspect ratio as 1920x1080.

>> (but do you really want such a low resolution ?)
>
> Only for the TTY.

This parameter forces the resolution in both X and TTY and does not
allow to select a lower (or higher) resolution.

> Actually I would like to have the old 80x25 text mode back we had in the
> 90s before the fancy framebuffer came along.

I'm afraid this is not possible.

> That should be possible (but
> how?), because the first boot messages appear to be in "plain text",
> before it switches to a higher resolution.

Before the KMS framebuffer driver is loaded.

> Btw. X works fine already. Don't want changes there.

Decent resolution in X requires the KMS driver.

> Okay, will on next boot (just updated rub with that)
> drm.edid_firmware=edid/640x480.bin and if this fails GRUB_GFXMODE=1024x768.

Just to be clear :
GRUB_GFXMODE is a GRUB parameter which affect the resolution in GRUB
menu only.
drm.edid_firmware is a kernel parameter which affects the resolution in
the TTY framebuffer and X.
You do not have to choose between one or the other.

Andreas Kohlbach <ank@spamfence.net> wrote:
> On Fri, 22 Apr 2022 20:17:19 +0200, Pascal Hambourg wrote:
>>
>> More like
>>
>> drm.edid_firmware=edid/640x480.bin
>>
>> (but do you really want such a low resolution ?)
>
> Only for the TTY.
>
> Actually I would like to have the old 80x25 text mode back we had in the
> 90s before the fancy framebuffer came along. That should be possible (but
> how?), because the first boot messages appear to be in "plain text",
> before it switches to a higher resolution.

The "vga=0" boot code selects 80x25 text mode. I tested it now
booting Linux kernel v. 5.15. Other text-mode options can be listed
if you boot with "vga=ask", marked as "VGA" instead of "VESA".

It seems to be using the BIOS font, so I guess it's not emulating
it with the framebuffer. Maybe later I'll try running a framebuffer
image viewer after it's booted like that and see what happens.

--
__ __
#_ < |\| |< _#

Computer Nerd Kev <not@telling.you.invalid> writes:

> The "vga=0" boot code selects 80x25 text mode.

Also vga=normal, although Grub complains about that and prefers
GRUB_GFXPAYLOAD_LINUX=text.

I use that since my HP server provides a kind of console over ssh but
weirdly it only supports 80x25 text mode.

Anssi Saari <as@sci.fi> wrote:
> Computer Nerd Kev <not@telling.you.invalid> writes:
>
>> The "vga=0" boot code selects 80x25 text mode.
>
> Also vga=normal, although Grub complains about that and prefers
> GRUB_GFXPAYLOAD_LINUX=text.

I've got fed up with Grub2, and if it's picky about which boot
codes you use then that makes yet another reason to avoid it. As
Grub Legacy is getting too awkward to use with modern stuff, I'm
moving to syslinux/extlinux instead.

I did some more testing and with vga=0, the text-mode font is
different on different PCs booted from the same live CD, so it's
definately not using the graphical framebuffer. Also when booted
that way, viewing images with fbv fails with "Open /dev/fb0: No
Such Device", so the framebuffer driver isn't loaded. X still works
fine displaying at a higher resolution with its VESA driver (and I
expected nothing less). Obviously the fbdev framebuffer driver for
X wouldn't work though.

> I use that since my HP server provides a kind of console over ssh but
> weirdly it only supports 80x25 text mode.

That makes sense really, it would have to be pretty smart to handle
sending a graphics-mode framebuffer console over ssh.

--
__ __
#_ < |\| |< _#

On Sat, 23 Apr 2022 10:23:14 +0200, Pascal Hambourg wrote:
>
> Le 23/04/2022 à 03:09, Andreas Kohlbach a écrit :
>> On Fri, 22 Apr 2022 20:17:19 +0200, Pascal Hambourg wrote:
>>>
> My bad, 640x480 is not supported. Lowest supported resolution is
> 800x600. I suggest trying 1920x1080 then 1680x1050 which has almost
> the same aspect ratio as 1920x1080.
>
>>> (but do you really want such a low resolution ?)
>> Only for the TTY.
>
> This parameter forces the resolution in both X and TTY and does not
> allow to select a lower (or higher) resolution.

Then it's no option.

[...]

>> Okay, will on next boot (just updated rub with that)
>> drm.edid_firmware=edid/640x480.bin and if this fails GRUB_GFXMODE=1024x768.
>
> Just to be clear :
> GRUB_GFXMODE is a GRUB parameter which affect the resolution in GRUB
> menu only.
> drm.edid_firmware is a kernel parameter which affects the resolution
> in the TTY framebuffer and X.
> You do not have to choose between one or the other.

Thanks. Will have to give up at this point.
--
Andreas

On Sat, 23 Apr 2022 10:23:14 +0200, Pascal Hambourg wrote:
>
> Le 23/04/2022 à 03:09, Andreas Kohlbach a écrit :
>
>> Okay, will on next boot (just updated rub with that)
>> drm.edid_firmware=edid/640x480.bin and if this fails GRUB_GFXMODE=1024x768.
>
> Just to be clear :
> GRUB_GFXMODE is a GRUB parameter which affect the resolution in GRUB
> menu only.
> drm.edid_firmware is a kernel parameter which affects the resolution
> in the TTY framebuffer and X.
> You do not have to choose between one or the other.

I rebooted! *LOL*

Before I put

GRUB_CMDLINE_LINUX_DEFAULT="gfxmode=640x480"

into GRUB, and it sort of worked. Now on the TTY "only" four letters are
missing on each side. A console font with large letters might "sort" that
out too.

Then I rebooted again to see what the BIOS is doing. And the page was
also almost completely displayed.

Strange to assume Linux told the TV to remember settings now, because the
popup indicating its resolution was still "1080p 60 Hz" like before when
all was messed up.

Btw. reboot also fixed my not working Bluetooth issue I reported here
months ago. Weeks ago I installed firmware but only after a massive power
sag yesterday I rebooted the computer for the very first time after
installing Mint in December last year.
--
Andreas