I was using this service file (found somewhere around here) to autologin and start X on boot:
[Unit]
Description=Direct login to X
After=systemd-user-sessions.service
[Service]
ExecStart=/bin/su fuchs -l -c "/bin/bash --login -c xinit"
[Install]
WantedBy=graphical.target
Now I'm autologing via
ExecStart=-/sbin/agetty --noclear -a USERNAME %I 38400
in getty@tty1 service and starting X on boot with
[[ $(fgconsole 2>/dev/null) == 1 ]] && startx -- vt1
in .profile as described in wiki.
Artefacts are gone and session is properly registered for authorization with polkit from testing. Only downside is it's not possible to log out on tty1. Even boot time is almost a second faster.
]]>When suspending to ram, all I see is black screen with cursor line, but when waking up, boot messages about started daemons are shown diagonally.
EDIT: Same thing happens after restarting X.
Exactly that, yea. Doesn't bother me too much, but what could be the cause?
]]>EDIT: Same thing happens after restarting X.
]]>I just hate that the console looks like a mess when suspending (text diagonally strewn across the screen).
It does? I definitely don't get this...
]]>I just hate that the console looks like a mess when suspending (text diagonally strewn across the screen).
Agreed, where does that come from?
]]>https://bugs.archlinux.org/task/31245
I assume it still works. *uses quiet*
You guys might want to "me too" the upstream bug report: https://bugs.freedesktop.org/show_bug.cgi?id=53937
]]>2ManyDogs wrote:alexanderthegre wrote:Dang... The colors are in a header file... I'm not going to be able to change that without major modifications to the code. Or a better knowledge of C. Probably both.
I don't understand this. Did you see earlier in this thread where flyingsheep located the colors in the code, and the discussion with Trilby that followed? Constants in a header file should be the easiest thing to change. You don't have to modify the code, just change the header file and rebuild.
Oops, I probably should have phrased that better. Anyway, what I was trying to say was that I couldn't, (read: don't know how to) make it read from a file within a header such that the user could, edit a file in, say, /etc/systemd-colors.conf and change the colors there.
If it has to be rebuildt, it probably will not work to just have an option in a settings file in etc, right? Then something has to be done with the sourcecode so that systemd actually will read that file.
]]>alexanderthegre wrote:Dang... The colors are in a header file... I'm not going to be able to change that without major modifications to the code. Or a better knowledge of C. Probably both.
I don't understand this. Did you see earlier in this thread where flyingsheep located the colors in the code, and the discussion with Trilby that followed? Constants in a header file should be the easiest thing to change. You don't have to modify the code, just change the header file and rebuild.
Oops, I probably should have phrased that better. Anyway, what I was trying to say was that I couldn't, (read: don't know how to) make it read from a file within a header such that the user could, edit a file in, say, /etc/systemd-colors.conf and change the colors there.
]]>Dang... The colors are in a header file... I'm not going to be able to change that without major modifications to the code. Or a better knowledge of C. Probably both.
I don't understand this. Did you see earlier in this thread where flyingsheep located the colors in the code, and the discussion with Trilby that followed? Constants in a header file should be the easiest thing to change. You don't have to modify the code, just change the header file and rebuild.
]]>