Hi,
I noticed that when my monitor runs at 60Hz, the cursor motion is really not smooth, even at low speed (it starts to be smooth at low speed when my monitor runs at 120/144Hz). Is there a way to improve this at the hardware level or is this a xserver issue? (I run everything git no older than 1/2 week/s).
regards,
On 2018-07-01 02:52 PM, sylvain.bertrand@gmail.com wrote:
If you have DC enabled, does disabling it (amdgpu.dc=0) help?
On 2018-07-02 11:24 AM, Michel Dänzer wrote:
Never mind, I missed that it's about Tahiti, which DC doesn't support.
Please share the corresponding Xorg log file.
What exactly does "not smooth" mean?
On Mon, Jul 02, 2018 at 11:29:19AM +0200, Michel Dänzer wrote:
I meant cursor motion is very blury, enough I can loose its location on the screen. And for instance, while moving the dota2 map with the grab method, at 60Hz it looks like moving the dota2 map at a sub-30Hz with some lag.
At 120/144Hz, cursor motion is way less blury, and dota2 map motion is smooth with the grab method.
On 2018-07-02 04:04 PM, sylvain.bertrand@gmail.com wrote:
I'm afraid I'm still not sure what "blurry motion" means exactly.
Is the behaviour different with the Xorg modesetting driver and/or the radeon kernel driver?
And for instance, while moving the dota2 map with the grab method, at 60Hz it looks like moving the dota2 map at a sub-30Hz with some lag.
Sounds like maybe DOTA doesn't use the X11 cursor (which would end up using the HW cursor), but renders the cursor as part of its scene.
Can you share the corresponding dmesg output and Xorg log file?
On Mon, Jul 02, 2018 at 04:22:47PM +0200, Michel Dänzer wrote:
I'm afraid I'm still not sure what "blurry motion" means exactly.
Like the mouse cursor location is updated very slowly, and that, only at 60Hz. (in dota2, it looks like sub-30Hz with lag).
Is the behaviour different with the Xorg modesetting driver and/or the radeon kernel driver?
I don't know, I would need to setup these and test (my custom distro is made for amdgpu).
Sounds like maybe DOTA doesn't use the X11 cursor (which would end up using the HW cursor), but renders the cursor as part of its scene.
Probably, but it happens only at 60Hz.
hum... the log was filtered out somewhere... Sending the logs as direct email to your personal email box.
On 2018-07-02 05:28 PM, sylvain.bertrand@gmail.com wrote:
Unless DOTA runs steadily at >= 60 Hz, there will sometimes be >= 33 ms between consecutive visible mouse cursor positions. This is correspondingly lower at higher refresh rate.
hum... the log was filtered out somewhere...
FWIW, I think I saw a bounce e-mail mentioning attachments being filtered due to them having multiple file name extensions.
(BTW, it looks like your mailer gets confused by my name or e-mail address as well)
Sending the logs as direct email to your personal email box.
Does using xf86-input-libinput instead of xf86-input-evdev help?
On Mon, Jul 02, 2018 at 06:43:48PM +0200, Michel Dänzer wrote:
Sending the logs as direct email to your personal email box.
Does using xf86-input-libinput instead of xf86-input-evdev help?
I did plan to switch to libinput in the futur, but:
I did test the xinput events and I get for a reasonable mouse motion speed an update of coords for each column of the screen (full hd).
It means that the cursor is supposely displayed for nearly all columns of the screen. For a fast mouse motion, the coord updates jump to a few tens of pixels. (1000Hz mouse)
Those numbers does not change from 60Hz to 144Hz, then I can rule out the input code.
If it's not my eyes or the screen itself, the pb will be in the cursor update code path from the xserver down to the driver...
The bottom of it is if I happened to see a system which has mouse motion which looks smooth for my eyes at 60Hz, I would get back to you on this issue.
regards,
On 2018-07-02 10:10 PM, sylvain.bertrand@gmail.com wrote:
Unless your xserver build ends up with INPUTTHREAD undefined for some reason, input events are processed in a separate thread, and the HW cursor position is updated accordingly ASAP.
On 2018-07-03 10:54 AM, Michel Dänzer wrote:
Also make sure you do not pass -dumbSched on the Xorg command line, and do not disable Option "SilkenMouse" in xorg.conf.
On Tue, Jul 03, 2018 at 11:01:46AM +0200, Michel Dänzer wrote:
Also make sure you do not pass -dumbSched on the Xorg command line, and do not disable Option "SilkenMouse" in xorg.conf.
No pb on this side. I tried to enable -dumbSched, I could not see any difference.
I did run a fast moving game at 60Hz, it was horrible, I ran it at 144Hz, smooth... the culprit may well be the monitor or my eyes.
Don't bother anyway, I'll wait for a more solid element of comparison. If I get one which is obvious to my eyes, I will get back to you on this matter.
On 2018-07-03 04:46 PM, sylvain.bertrand@gmail.com wrote:
Yeah, we've pretty much ruled out any possible software issue at this point. :)
Regarding the monitor, maybe double-check its settings for anything (e.g. picture quality / post processing) which might delay its output.
dri-devel@lists.freedesktop.org