Hello. My first time installing sarpi on my rpi4 4 Gb.

1. The biggest problem is a wrong display mode. I've tried on two monitors: 1920x1080@60 and 2560x1440@60. In both cases image has a huge borders around like 100+ pixels. In fullscreen or even maximized mode I don't see respective parts of applications. They are hidden in this strange borders. xrands shows only 1 output - default and only 1 mode - 18*x9* for 1920x1080 and same for 1440p monitor. AFAIK raspberry pi OS have an option to fix this during first boot. Is there any fix for sarpi? Uncommenting 'disable_overscan=1` option in /boot/config.txt doesn't work too.

2. I don't use DM (no need), but I'd like to autologin and autostart X after boot as normal user. I found how to autostart X, but all suggestions I've found on LQ so far just don't work. I've tried change inittab to add agetty autologin (rpi doesn't boot after rainbow screen), add something like to /etc/rc.d/rc.local (boot freezes on atd). Any reliable way to autologin?

3. Every boot of sarpi system time goes back to 1970. I don't actually understand why. ntpd doesn't solve my problem, because my router has no ntp server and rpi is blocked from the rest of the world (no internet connection).

mplayer doesn't seem to work properly too. -geometry option cuts video in a strange way. E.g. I run

and get 80% of real image. The rest is for some reason hidden even for video lower then 540p. It can be fixed by manually resizing the window using mouse. Very strange behavior. Haven't experienced it on raspberry pi OS.

Hi Nedderokumo

Display can be a headache if the screen/monitor you're using does not support the display mode that the Raspberry Pi is generating. Have you tried using both video ports on the RPi4 and compared them? You might benefit from playing around with the 'overscan_left', 'overscan_top' (etc.) config.txt settings to try and solve your display problem. You could also try setting 'hdmi_safe=1' too.

I'm sure there is a way to autologin and startx with your chosen desktop environment "à la Ubuntu style" but I don't know off the top of my head how to achieve it. Nor would I be interested in doing do with Slackware. Perhaps someone more familiar with this subject can advise you, as I am a CLI Slackware user for 99.999% of the time.

The way to set accurate time at boot is if you have a battery backed-up real time clock and/or Internet connection to set the time from a NTP server. Otherwise it's down to setting it manually each time you (re)boot the device.

Exaga, thanks for the reply.

I'm a slowpoke. I should use whole config.txt from RPOS from the beginning. The problem is solved.

I don't use DE, I use fluxbox. The thing is to make boot-login-startx process absolutely automatic, because the next step is to play video with mplayer, which was previously set up in fluxbox startup config. Unfortunately, I've no idea how to make autologin work.

My 2 cents about date/time... Again I can compare with RPOS, and in RPOS on this rpi4 date and time doesn't go back to 1970 between reboots without internet access and ntp sync. I don't replug rpi, just use shutdown -r command. Last night I tried ubuntu as well. Date and time were accurate between reboots. Seems like sarpi has something configured in another way.

When it comes to my problem with mplayer. Firstly, I thought it would be solved when I solve black borders problem. I was wrong. Mplayer still behave in a strange way. Exactly the same command works flawlessly on my desktop amd64 slackware current.

The config.txt file settings and options is a huge list. Usually there's a way for users to solve most issues by invoking and/or manipulating them.

Raspberry Pi OS (formally known as Raspbian) and Slackware ARM (not SARPi) are two different systems. SARPi is just an installer for Slackware ARM on the Raspberry Pi devices and is not an operating system. Slackware ARM is an operating system.

My guess is that 'fake-hwclock' is the reason why relatively accurate time is retained on reboot for operating systems which feature it, such as Raspberry Pi OS and Ubuntu. Slackware does not include a 'fake-hwclock' function. The 'fake-hwclock' is designed to give systems a method of setting a chronological datum where a network connection or RTC is unavailable, like on a lot of embeded systems. After rebooting a system that runs the 'fake-hwclock' any time jitter offset may be negligible or go unnoticed.

https://manpages.debian.org/jessie/f...lock.8.en.html



[EDIT] found this on GitHub which may interest you... https://github.com/xanmanning/alarm-fake-hwclock