Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
This is a problem with a Raspberry Pi running slackware64-15.0 (Slarm64). My kernel is overscanning on kernel 6.0.2 after reinstallation. I have updated the OS, but as the kernel overscans before the OS is loaded, I can narrow the issue down to kernel or initrd, and not the OS.
The RazPi boots in a crazy way, and does a lot before loading the kernel. The file /boot/config.txt configures or switches a lot of hardware. With kernel 5.16.7, the Pi overscanned, but these settings in config.txt fixed the overscan issue
With kernel 6.0.2, I've tried 0, 32, & 64 in those lines and they haven't improved the overscan by a single pixel. That's a PITA, because all I can do is hit Ctrl_Alt_F2, log in & shut down.
Thanks for the reply. I have a HDMI screen, so I tried "video=1860x1000-24@60" and it initially booted showing a smaller screen with edge margins.
But 5-10 seconds in, the video driver loaded, whereupon the overscanning resumed. This is actually very bad news for me, as I feel a kernel bug report coming on, with all the consequent hassle & aggrevation.....
There are (typically) 2 files in the Raspberry Pi where you can put changes to the initial configuration, IIRC
/boot/cmdline.txt which is in effect the boot options passed to every kernel
/boot/config.txt, which is a sort of general hardware setup thing that gets configured before the kernel is loaded.
You'd think I was an expert the way I'm sounding off, but I assure you that's not the case.
Having tried cmdline.txt, I'll definitely try the other (/boot/config.txt) tomorrow, and see what effect it has. I would accept that my tv could be displaying a smaller area, but the fact remains that the 5.16.7 system responded to config.txt settings, whereas the 6.0.2 one does not. I'll update that tomorrow also as 6.0.6 is offered. It's Halloween tonight here - a big Satanic pagan thing that nearly all Christian religions seem to go for, fireworks are continuous, the dog needs tranquilisers. Outside sounds like a war zone and it is not the time to try playing busy on the pc.
Last edited by business_kid; 10-31-2022 at 04:01 PM.
Thanks for the reply. I have a HDMI screen, so I tried "video=1860x1000-24@60" and it initially booted showing a smaller screen with edge margins.
Did you consider the options in that URI that I did not include in my example? Try video=1920x1080-24@60m. The 1.8% margin addition should eliminate the overscan without penalizing quality via a non-native mode. Of course, video= only applies to the vttys.
To handle overscan in Xorg on a PC driving an ordinary HDTV display, I used xrandr:
in /etc/X11/xinit/xinitrc.d/##-somefile in openSUSE, which on Debian I would have put in /etc/X11/Xsession.d/##-somefile. ## represents any two digit number suitable for having the file read and executed at an appropriate time in the boot sequence. Typically mine are put in the 40-50 range. Experimenting may be required.
The 1.8% margin addition should eliminate the overscan without penalizing quality via a non-native mode.
The Raspberry Pi lot are funny. It's the other way around. Adding an "Overscan=" setting actually adds underscan.
I tried researching /boot/config.txt options and tried a few. Unfortunately, a number of the less used config.txt options have been dropped, and a few new ones have been added. Additionally, the Pi 4B is regarded as "A more powerful computer" than the Razpi 0-3 which it marginally is. so the config.txt stuff for that id different, & should be separate, but isn't usually. Anyhow I chose my HOSTNAME with it's power in mind. It's called 'SparrowFart."
Here's what I tried to fix my problem:
hdmi_safe # Supposed to give overscan of 24 all round with regular hdmi. It had no effect.
hdmi_ignore_edid # is supposed to ignore what the monitor is telling you. But in that case, you're supposed to have a better edid in /boot to point the box at, which I didn't. No change anyhow.
video=<some size> # I've previously found this setting referenced in config.txt, although I'm not finding it now. It did nothing anyhow.
There's also the question of what the thing does with a non-standard setting. Does it say 'He wants me to display on less of the screen' and trim it's width? Or is it 'Oh, there's fewer dots than I thought' and zoom the picture to fit the known width (which may well be too big)?
Either way, it's my "Just in case" system, and I sorted it. In X, I changed DPI to 1440x1050(?) and I got up a 16:9 mode which was the correct width, and showing the taskbar. I presume the height was good too, as my monitor always centres the picture. I don't need "Just in case" with hdmi.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.