High CPU usage from Xorg

Periodically, htop shows that the command

/usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root:0 -nolisten tcp vt7 -novtswitch

is using about 92% of one virtual core. It does this after starting up, and then it does it periodically while running. Aside from eating up resources, using XCFE shortcut keys is very slow (the command is delayed by minutes).

I'm using Intel's integrated graphics adapter. I noticed that the directory /usr/share/X11/xorg.conf.d/ contains the file 10-amdgpu.conf. Also, running cat /usr/share/X11/xorg.conf.d/10-amdgpu.conf outputs this:

Section "OutputClass"
	Identifier "AMDgpu"
	MatchDriver "amdgpu"
	Driver "amdgpu"

This might well be unrelated, but it looks strange to me as I have no AMD GPU.

Does anyone know how this problem might be resolved?

Is there any pattern to what you are doing at the time the CPU usage spikes, such as watching/editing video, etc.?

Regarding the /usr/share/X11/xorg.conf.d/10-amdgpu.conf output, I get the same on this here Zareason machine all-Intel inside machine running Slackware. I suspect the "amd" refers, not to the video card, but to the 64-bit architecture, which is commonly referred to as "amd" in Linux world.

It happens after I boot and login. I'm not aware of any other pattern. Searching for "xorg lightdm high cpu usage" returns a lot results, but no promising leads.

Hey, I actually have exactly the same problem on Debian Stretch stable, after I changed a few things on my system : One core fully used for about 2 minutes on every login (after sleep, hibernate, even login in other tty) by Xorg with this line in htop :

Xorg :0 -seat seat0 -auth /var/run/lightdm/root:0 -nolisten tcp vt7 -novtswitch

And during this time, xfce shortcuts are very slow/not working, but only the keyboard applications shortcuts, not the window manager keyboard shortcuts (which is strange, since they are in the same file if I recall well, but in different menus in the settings).

I started a list of all the stuff I did before it started happening, but I did do a lot of things and am not sure exactly when this started.
If you're interested, we can share and cross check our personnal settings to try and find out where it comes from.

I'll post later on some more info about what I did that could have led to this

Originally Posted by Ganth Hey, I actually have exactly the same problem on Debian Stretch stable, after I changed a few things on my system : One core fully used for about 2 minutes on every login (after sleep, hibernate, even login in other tty) by Xorg with this line in htop : Xorg :0 -seat seat0 -auth /var/run/lightdm/root:0 -nolisten tcp vt7 -novtswitch And during this time, xfce shortcuts are very slow/not working, but only the keyboard applications shortcuts, not the window manager keyboard shortcuts (which is strange, since they are in the same file if I recall well, but in different menus in the settings). I started a list of all the stuff I did before it started happening, but I did do a lot of things and am not sure exactly when this started. If you're interested, we can share and cross check our personnal settings to try and find out where it comes from. I'll post later on some more info about what I did that could have led to this

I've the same problem with application shortcuts when resuming session from locked screen. Same process keeps 1 CPU 90-100% for 5 minutes.

Did you fixed your problem?

Originally Posted by Ganth Hey, I actually have exactly the same problem on Debian Stretch stable, after I changed a few things on my system : One core fully used for about 2 minutes on every login (after sleep, hibernate, even login in other tty) by Xorg with this line in htop : Xorg :0 -seat seat0 -auth /var/run/lightdm/root:0 -nolisten tcp vt7 -novtswitch And during this time, xfce shortcuts are very slow/not working, but only the keyboard applications shortcuts, not the window manager keyboard shortcuts (which is strange, since they are in the same file if I recall well, but in different menus in the settings). I started a list of all the stuff I did before it started happening, but I did do a lot of things and am not sure exactly when this started. If you're interested, we can share and cross check our personnal settings to try and find out where it comes from. I'll post later on some more info about what I did that could have led to this

Originally Posted by peledzius I've the same problem with application shortcuts when resuming session from locked screen. Same process keeps 1 CPU 90-100% for 5 minutes. Did you fixed your problem?

i'll concede that high cpu usage by Xorg is tricky and difficult to troubleshoot (because usually other applications are responsible for it; i think it's a graphics thing).
but this is not "the same problem".
also, OP never fully analysed their own problem.
right now i don't know how to do that either; if i was you i'd start with a search.

Originally Posted by peledzius I've the same problem with application shortcuts when resuming session from locked screen. Same process keeps 1 CPU 90-100% for 5 minutes. Did you fixed your problem?

Hi! Well, actually, no, as my computer fried at Christmas (it was a W520 ; I know, this shouldn't happen). So I never will be able to try to solve it or update, sorry.
What died was the graphics actually, as soon as anything graphic started it froze and only a manual power-button hard reboot was possible (and I know about the Nvidia/optimus mess, I could handle it well, it wasn't this and anyway it's off topic).
But maybe my Xorg problems where symptoms of this ?

Originally Posted by ondoho i'll concede that high cpu usage by Xorg is tricky and difficult to troubleshoot (because usually other applications are responsible for it; i think it's a graphics thing). but this is not "the same problem". also, OP never fully analysed their own problem. right now i don't know how to do that either; if i was you i'd start with a search.

Ok, thanks for the info, I hadn't realized this. In my case, my problem precisely was that I had no logs that seemed to hint to the problem, nor in journalctl, dmesg or the Xorg log. This would have surely required much more digging/thread opening and I hadn't found the time... (and usually I manage to find something, thus my (maybe totally wrong) supposition that it could be linked to my upcoming hardware failure).
Anyway, well... good luck to anybody else trying to fix a similar problem!