[SOLVED] After last Pacman update, screen size is reduced

Francuss · 2018-10-04 11:03:55

Trilby wrote:

Then find the problem in your configs. Perhaps this would give a good start:
grep -rl randr ~/.config/awesome/*
Then check any file that is listed for any use of 'xrandr', 'arandr', or similar commands.

No awesome folder in .config

[f@F]: ~>$ grep -rl randr ~/.config/awesome/*
grep: /home/f/.config/awesome/*: No such file or directory
[f@F]: ~>$

Francuss · 2018-10-04 11:19:30

seth wrote:

Also (since the switch comes fairly early) - did you check your DMs config files?
And to get ahead of your next question: your distro (or some person) installed lightdm for you, it's configuration is in /etc/lightdm/

yes, there is a lightdm folder and inside a lightdm.conf file:
https://ptpb.pw/nL7_
but I can see no reference to a wrong resolution

seth · 2018-10-04 12:39:23

How can there be no awesome config dir if you're running awesome???

loginctl session-status

Francuss · 2018-10-04 13:55:27

seth wrote:

How can there be no awesome config dir if you're running awesome???
loginctl session-status

https://ptpb.pw/Sagd

seth · 2018-10-04 14:17:10

Ok, you're running a completely unconfigured awesome, there's no lightdm related mode change and no modeline/preferred mode in your xorg config, yet something™ alters the mode very early.

1. take lightdm out of the equation, use xinit/startx to start X and awesome, see https://wiki.archlinux.org/index.php/Xinit
2. move away xrandr and arandr (eg. from /usr/bin to /usr) to see whether they're invoked here

Francuss · 2018-10-04 14:52:36

seth wrote:

Ok, you're running a completely unconfigured awesome, there's no lightdm related mode change and no modeline/preferred mode in your xorg config, yet something™ alters the mode very early.
1. take lightdm out of the equation, use xinit/startx to start X and awesome, see https://wiki.archlinux.org/index.php/Xinit

All that seems really very complicated, but I will try to do what can.

2. move away xrandr and arandr (eg. from /usr/bin to /usr) to see whether they're invoked here

you mean moving these files to /usr ?

[f@F]: ~>$ ls /usr/bin/*randr
/usr/bin/arandr  /usr/bin/unxrandr  /usr/bin/xrandr
[f@F]: ~>$

seth · 2018-10-04 15:05:17

Yes. If they're invoked by whatever causes this, the switch won't happen. (You can also just rename them to /usr/bin/not.xrandr or whatever)
xinit is not complicated at all.

Francuss · 2018-10-04 15:35:09

seth wrote:

Yes. If they're invoked by whatever causes this, the switch won't happen. (You can also just rename them to /usr/bin/not.xrandr or whatever)
xinit is not complicated at all.

renamed the files, rebooted, but resolution is still the wrong one.

Also something is starting X now, if I install xinit, there will be two agents starting X at the same time. Isn't this a cause of conflict among them or the same sort of mess we wanted to avoid when I proposed the sh file that sets the proper resolution after boot?

Last edited by Francuss (2018-10-04 16:25:03)

seth · 2018-10-04 21:44:23

If you merely install xinit (startx), nothing will happen at all.
You've to configure it, disable lightdm (or boot into the muti-user.target, see https://wiki.archlinux.org/index.php/Sy … boot_into), login to the console and xinit/startx there.
And that's not at all related to any mess related to any solution - this step is just to isolate the cause.

Francuss · 2018-10-05 02:30:27

seth wrote:

If you merely install xinit (startx), nothing will happen at all.
You've to configure it, disable lightdm (or boot into the muti-user.target, see https://wiki.archlinux.org/index.php/Sy … boot_into), login to the console and xinit/startx there.
And that's not at all related to any mess related to any solution - this step is just to isolate the cause.

So installed xorg-xinit package.

File .xinitrc seems to know it should start awsome infact the only setting is

exec awesome

After a lot of attempts understood I should not run startx in a terminal, rather reboot and at the login screen use the shortcut Alt+Ctrl+F2, then there try startx on the console. And you wrote it was easy.

Anyway it worked, it started X and awesome with the correct resolution!!! Which seems great news.

So I try to imagine that now I have to create ~/.xserverrc which does not exist with this content:

#!/bin/sh

exec /usr/bin/Xorg -nolisten tcp "$@" vt$XDG_VTNR

to make the change permanent. Is that so?

Last edited by Francuss (2018-10-05 02:55:59)

seth · 2018-10-05 06:18:49

* You do not have to create an xserverrc at all
* The xinitrc is *not* sane w/ only "exec something", revisit the link about what to at least add
* You should tr-try this w/o an X server running on any console, boot into or isolate the multi-user.target
* This however already strongly suggests that the issue is in lightdm

If you want to drop lightdm, disable the service and if you want to automatically start your session on boot, see https://wiki.archlinux.org/index.php/Xi … X_at_login and ensure to also see the link in the "Tip" box.

Francuss · 2018-10-05 12:44:06

seth wrote:

* You do not have to create an xserverrc at all
* The xinitrc is *not* sane w/ only "exec something", revisit the link about what to at least add

added
exec cbatticon
but the battery widget does not appear
also added the last if block in /etc/X11/xinit/xinitrc

* This however already strongly suggests that the issue is in lightdm
If you want to drop lightdm, disable the service

this also seems complicated. What about a simple sudo pacman -R lightdm ?

and if you want to automatically start your session on boot, see https://wiki.archlinux.org/index.php/Xi … X_at_login

at the bottom of ~/.bash_profile added

if [[ ! $DISPLAY && $XDG_VTNR -eq 1 ]]; then
  exec startx
fi

but nothing seems to change. I imagine the culprit is the login GUI

Last edited by Francuss (2018-10-05 12:49:16)

seth · 2018-10-05 13:05:00

Nothing after the first "exec" call is processed.
Therefore also ensure you didn't append the if block, but have it before the exec call.
You shall not remove, but just disable it - and that's not complicated at all. "systemctl disable lightdm.service"…

Francuss · 2018-10-05 18:13:42

seth wrote:

Nothing after the first "exec" call is processed.
Therefore also ensure you didn't append the if block, but have it before the exec call.
You shall not remove, but just disable it - and that's not complicated at all. "systemctl disable lightdm.service"…

Ok, the GUI login does not appear anymore and everything works as supposed.

Many thanks for the generous help

Arch Linux

#26 2018-10-04 11:03:55

Re: [SOLVED] After last Pacman update, screen size is reduced

#27 2018-10-04 11:19:30

Re: [SOLVED] After last Pacman update, screen size is reduced

#28 2018-10-04 12:39:23

Re: [SOLVED] After last Pacman update, screen size is reduced

#29 2018-10-04 13:55:27

Re: [SOLVED] After last Pacman update, screen size is reduced

#30 2018-10-04 14:17:10

Re: [SOLVED] After last Pacman update, screen size is reduced

#31 2018-10-04 14:52:36

Re: [SOLVED] After last Pacman update, screen size is reduced

#32 2018-10-04 15:05:17

Re: [SOLVED] After last Pacman update, screen size is reduced

#33 2018-10-04 15:35:09

Re: [SOLVED] After last Pacman update, screen size is reduced

#34 2018-10-04 21:44:23

Re: [SOLVED] After last Pacman update, screen size is reduced

#35 2018-10-05 02:30:27

Re: [SOLVED] After last Pacman update, screen size is reduced

#36 2018-10-05 06:18:49

Re: [SOLVED] After last Pacman update, screen size is reduced

#37 2018-10-05 12:44:06

Re: [SOLVED] After last Pacman update, screen size is reduced

#38 2018-10-05 13:05:00

Re: [SOLVED] After last Pacman update, screen size is reduced

#39 2018-10-05 18:13:42

Re: [SOLVED] After last Pacman update, screen size is reduced

Board footer