Issue with starting xorg

Code:
[   112.596] (II) Loading /usr/local/lib/xorg/modules/drivers/intel_drv.so
[   112.655] (II) Module intel: vendor="X.Org Foundation"
[   112.655] 	compiled for 1.21.1.16, module version = 2.99.917
[   112.655] 	Module class: X.Org Video Driver
[   112.655] 	ABI class: X.Org Video Driver, version 25.2
pkg delete xf86-video-intel you don't need it.

Facing issues with Xorg GUI login!
What exactly is the problem? Your X config looks fine, no issues.
 
Please post your /etc/sddm.conf, /usr/local/etc/sddm.conf, what you have in /etc/sddm.conf.d/ and /var/log/sddm.log
 
Might i ask whether there is a history of all the installed packages that were there previously?
Package actions (deleting, installing, etc) are recorded in /var/log/messages. pkg(8) doesn't have a history like yum/dnf has though.
 
Hi

Still facing issues with xorg, not able to do GUI login.


Thanks
rraj
Link is broken (excessive "." at the end).

Looking into the log (by removing final "."),
Code:
[ 14753.496] Parse error on line 1 of section InputClass in file /etc/X11/xorg.conf
    "FontPath" is not a valid keyword in this section.
[ 14753.496] (EE) Problem parsing the config file
[ 14753.496] (EE) Error parsing the config file
suggest broken config file(s).

And
Code:
[ 14753.496] (EE)
Fatal server error:
[ 14753.496] (EE) no screens found(EE)
[ 14753.496] (EE)
suggests no GPU nor framebuffer is found, even though you have Intel GPU (according to the last /var/log/messages you uploaded at pastebin on comment #12).

What I suspect is your user (or user for GUI login manager) is fatally broken as of below.
Code:
localhost login[59371]: login_getclass: unknown class 'video'
localhost syslogd: last message repeated 3 times
localhost login[59371]: ROOT LOGIN (root) ON ttyv0

Did you use vipw(8) for creating user? Or specified option "-L" with "video" on adduser(8)?
In the former case, possibly you've entered "video" in 5th element (separated with ":"). Or did the latter case.
This is clearly wrong on usual installation as there shouldn't be video class.

Users who want to use X and / or Wayland with DRM drivers needs to be in video "group", not video "class". And element for group is the 4th element.
5th element is usually blank (nothing within ":" at the end of 4th element and at the beginning of 6th element, like "::").
If the 4th element of the user's entry in /etc/master.passwd is NOT video AND "video" line in /etc/group doesn't contain the user, no screen should be found.

remove /etc/X11/xorg.conf
This shouldn't be done, as it make it difficult to dig in deeper later, if needed.
Instead, renaming to something that is NOT end with ".conf" is suggested.
 
remove /etc/X11/xorg.conf

This shouldn't be done, as it make it difficult to dig in deeper later, if needed.
Instead, renaming to something that is NOT end with ".conf" is suggested.
Quoting from Chapter 5. The X Window System, 5.5.1.
Historically, the X.org server was configured with files in /usr/local/etc/X11/. This is still supported for edge cases, but conflicts with dynamic autoconfiguration.
Please, note /usr/local/etc/X11/ and not /etc/X11/
Do not create configuration for the X.org server in xorg.conf or run Xorg -configure unless automatic configuration fails.
That's why I said that /etc/X11/xorg.conf should be removed, especially because it's failing on the first line.
We well get much clearer picture from /var/log/Xorg.0.log about why and where autoconfigure fails if there is no faulty /etc/X11/xorg.conf
 
Quoting from Chapter 5. The X Window System, 5.5.1.

Please, note /usr/local/etc/X11/ and not /etc/X11/

That's why I said that /etc/X11/xorg.conf should be removed, especially because it's failing on the first line.
We well get much clearer picture from /var/log/Xorg.0.log about why and where autoconfigure fails if there is no faulty /etc/X11/xorg.conf
No. At least, filename which doesn't end with ".conf" is ignored.

For example, by renaming /etc/X11/xorg.conf to, for example, /etc/X11/xorg.conf.20250913, X11 cannot consider it as its configuration file.

So deleting it AFTER every problems are completely fixed is not too late.
Renaming is sufficient.
 
No. At least, filename which doesn't end with ".conf" is ignored.

For example, by renaming /etc/X11/xorg.conf to, for example, /etc/X11/xorg.conf.20250913, X11 cannot consider it as its configuration file.

So deleting it AFTER every problems are completely fixed is not too late.
Renaming is sufficient.
We can debate about strategy, and in principle I agree that mv foo.bar foo.bar.orig is safer than rm foo.bar, but I can't remember any more on which version back I had xorg.conf anywhere, especially not in the /etc/X11/ dir.

I only have few .conf files in the /usr/local/etc/X11/xorg.conf.d/, named as per Section/Identifier that they used to be in while xorg.conf was still used.
 
We can debate about strategy, and in principle I agree that mv foo.bar foo.bar.orig is safer than rm foo.bar, but I can't remember any more on which version back I had xorg.conf anywhere, especially not in the /etc/X11/ dir.

I only have few .conf files in the /usr/local/etc/X11/xorg.conf.d/, named as per Section/Identifier that they used to be in while xorg.conf was still used.
I have several dated (having .<date> like xorg.conf.20220119 and so on) xorg.conf files in my /etc/X11/ directory as backups and no file named xorg.conf there. And all of them are silently ignored as is there's nothing.

And I cannot delete them for times I need to test non-DRM nvidia drivers.
 
I have several dated (having .<date> like xorg.conf.20220119 and so on) xorg.conf files in my /etc/X11/ directory as backups and no file named xorg.conf there. And all of them are silently ignored as is there's nothing.

And I cannot delete them for times I need to test non-DRM nvidia drivers.
Well, rraj has HD Graphics 5500, so all that is needed is
Code:
su - 
pkg install drm-kmod 
pw groupmod video -m <username> 
sysrc kld_list+="i915kms" 
shutdown -r now

then startx (without /etc/X11/xorg.conf, move it somewhere, rename it, whatever) and if X still fails, post again /var/log/Xorg.0.log which will then give us better picture about what's going on. Also, it will be beneficial to see ~/.xinitrc and if sddm is used ~/.local/share/sddm/xorg-session.log
 
Back
Top