[SOLVED] Cursor oddity under backported kernel

Geoff 42 · 2021-04-11 10:32:11

I was investigating an error message (unrelated to the cursor) when I installed the backports kernel. This did not fix the unrelated problem, but it did produce an odd effect on the cursor.

I was running Beowulf with the 4.19.0-12 kernel and then installed 5.10.0-0.bpo.3-amd64.
I am using LXQt, with Openbox.
On Intel hardware and graphics.

With the backports kernel, the cursor is very slow to change as I move over different areas. Thus, as I move over the corner of a window, it can take 4 or 5 seconds for the cursor to complete the change from an arrow to the L shaped corner drag cursor. This does not happen on the 4.19 kernel.

I have had a quick search and have not found any references to this behaviour. Does this mean anything to anyone?

Geoff

Head_on_a_Stick · 2021-04-11 10:45:42

Does removing the xserver-xorg-video-intel package help? The Intel DDX driver is reportedly pretty buggy, Debian recommend using X's builtin modesetting driver instead.

Or just use an X.Org configuration file to test the modesetting driver: http://dev1galaxy.org/viewtopic.php?pid=28863#p28863

Geoff 42 · 2021-04-11 11:20:01

Thank you for your suggestions.

I have created the file /etc/X11/xorg.conf.d/00-modesetting.conf, as suggested in your indicated posting, containing :-

Section "Device"
   Identifier "Intel Graphics"
   Driver "modesetting"
EndSection

And rebooted into the 5.10 kernel, but the cursor problem is still there.

I notice that the word modesetting is used. This may be related to the problem I was trying to investigate! This was that dmesg reports :-

broken atomic modeset userspace detected, disabling atomic

This occurs with both kernels. I don't know whether it is a red herring!

Geoff

Head_on_a_Stick · 2021-04-11 11:42:15

Geoff 42 wrote:

whether it is a red herring

Probably. See https://www.phoronix.com/scan.php?page= … ble-Atomic

There are fixes for the atomic modesetting glitches but X is now abandonware so they are unlikely to ever be applied.

EDIT: is there anything printed in the X.Org log when you experience the problem?

Last edited by Head_on_a_Stick (2021-04-11 11:45:39)

Altoid · 2021-04-11 12:41:05

Hello:

Head_on_a_Stick wrote:

... but X is now abandonware ...

Hmm ...
Maybe it's too soon to sign the certificate?
There's still much to be said.

Many years ago (unfortunately much later than I should have) one day I realised that I could always solve any apparent confusion or contradiction by stepping back and having a close look at what was going on with the purpose of getting a grasp of who was where and why.

While the why part of the exercise many times remained (as it usually does) unknown, the who and where have always proved to be quite revealing.
The end result being that whatever confusion or contradiction I may have had cleared up very quickly.

To wit:
I realised I was definitely a Democrat by the age of 13 not because of my reading of the opinion pieces of the two newspapers I delivered every afternoon but by listening to what Mr. Davis, my next door neighbour and certified dyed in the wool Republican had to say about things in general.
I'll always be grateful to the old chap for that.

With respect to the matter of X, if Red Hat, IBM et al are attempting to sink it, don't count me in.
I have faith in the resilience of the Linux ecosystem albeit not in its constituents.

Just my 0.02.

A.

Last edited by Altoid (2021-04-11 12:41:59)

Head_on_a_Stick · 2021-04-11 12:54:48

Altoid wrote:

Hello:
Head_on_a_Stick wrote:
... but X is now abandonware ...
Hmm ...
Maybe it's too soon to sign the certificate?

The maintainer of the X codebase described it as such himself: https://ajaxnwnk.blogspot.com/2020/10/o … erver.html

Altoid wrote:

With respect to the matter of X, if Red Hat, IBM et al are attempting to sink it, don't count me in.
I have faith in the resilience of the Linux ecosystem albeit not in its constituents.

X has been maintained by Red Hat almost exclusively because nobody else has bothered. Now they can't be bothered either. It's not a case of "trying to sink it", much as the conspiracy theorists would like to convince themselves otherwise.

But this is all off-topic for this thread so we should probably continue any discussion in your other thread.

Altoid · 2021-04-11 13:13:28

Head_on_a_Stick wrote:

... off-topic for this thread ...

Quite so.
Thanks for pointing it out. 8^)

Best,

A.

Geoff 42 · 2021-04-11 13:53:10

Head_on_a_Stick wrote:

EDIT: is there anything printed in the X.Org log when you experience the problem?

There is a lot of stuff in the Xorg.0.log file and I can't see anything which tells me anything helpful. I will carry on looking at the xserver-xorg-video-intel package.

Geoff 42 · 2021-04-11 14:20:18

I have now removed the xserver-xorg-video-intel package, which made no difference, either with or without /etc/X11/xorg.conf.d/00-modesetting.conf.

Geoff 42 · 2021-04-11 14:30:59

I have just had a thought! I usually have the Xen hypervisor running, so I thought that I should try booting the backports kernel on the bare metal. This seems to remove the problem. I will continue to look to see if I can find what causes the problem.

Thank you for your help.

The officially official Devuan Forum!

#1 2021-04-11 10:32:11

[SOLVED] Cursor oddity under backported kernel

#2 2021-04-11 10:45:42

Re: [SOLVED] Cursor oddity under backported kernel

#3 2021-04-11 11:20:01

Re: [SOLVED] Cursor oddity under backported kernel

#4 2021-04-11 11:42:15

Re: [SOLVED] Cursor oddity under backported kernel

#5 2021-04-11 12:41:05

Re: [SOLVED] Cursor oddity under backported kernel

#6 2021-04-11 12:54:48

Re: [SOLVED] Cursor oddity under backported kernel

#7 2021-04-11 13:13:28

Re: [SOLVED] Cursor oddity under backported kernel

#8 2021-04-11 13:53:10

Re: [SOLVED] Cursor oddity under backported kernel

#9 2021-04-11 14:20:18

Re: [SOLVED] Cursor oddity under backported kernel

#10 2021-04-11 14:30:59

Re: [SOLVED] Cursor oddity under backported kernel

Board footer