[SOLVED-ish] UHD 620 Xorg 30 FPS Video Issues

why_do_i_need_a_username · 2024-08-31 07:26:04

I recently got a (non-dGPU, iGPU only, Intel UHD 620) ThinkPad T480 and while for running Linux, it's an acceptable machine, I haven't been able to actually set a desktop environment for long-term use because...

1. Wayland cursor input lag: Seemingly everything Wayland-based that I've tried running on this thing causes the cursor to have a weirdly noticeable lag to it, regardless of the input device in use. I thought that this was a touchpad issue, but it happens with an external mouse as well. Again, everything that uses Wayland does this, so this might be something inherent to the protocol (forced vsync maybe?), but, then again, my previous laptop (actually had a newer CPU and graphics than this, CPU-wise it's similar but graphics... ehhh... both machines have an Intel iGPU only), or maybe all the compositor devs just so happen to be doing cursor stuff in the same not-so-great (?) way (this happens on everything wlroots-based but also on GNOME/mutter which is separate from that because GNOME devs are GNOME devs), or maybe this iGPU (or more likely its Linux drivers) just isn't that great at doing Wayland, which wouldn't be *too* surprising, older GPUs generally suck at it but then again, this isn't *that* old, 6-ish years old, sure, but...

2. Can't do 30 FPS under Xorg properly: So if Wayland isn't an option, then the only other option (besides plain tty, running Windows, or having no computer at all) is Xorg, which would be *tolerable* if it wasn't for the fact that I seemingly can't get 30 FPS video to play smoothly under it. Ironically, 60 FPS actually works fine[TM] in mpv and in Firefox as well but for the latter you need to disable sound because it will actually drop frames, not because of X11 but because of Pipewire, more specifically, because of it going through pipewire-pulse rather than pipewire natively (at least I recall that being an issue and haven't checked in on it, I've simply assumed that "browser + pipewire + 60fps = frame drops" for the last year or so because it definitely was true then and was true even 6 months ago), but 30 FPS drops frames (or at least microstutters frequently) with both of those. This happens even with videos playing in fullscreen, which is not the case with both Wayland and mpv's --vo=drm (basically running mpv with no display server inbetween), so...

This is my /etc/X11/xorg.conf.d/20-intel.conf:

Section "Device"
  Identifier "Intel Graphics"
  Option "AccelMethod" "sna"
  Option "DRI" "iris"
  Option "SwapbuffersWait" "false"
  Option "TearFree" "false"
  Option "TripleBuffer" "false"
  Driver "intel"
EndSection

I am using xf86-video-intel instead of the modesetting driver because that one is even worse for this kind of thing, and I have tried various combinations of TearFree, SwapbuffersWait, TripleBuffer, etc. with various compositors (for reference, I am running Arch with xfce but have xfwm4's compositor disabled so I can use another one), and what seems to work best is picom with the fade and transparency stuff turned off, with "xrender" as the backend and with the above xorg.conf settings, at least for playing 60 FPS video. 30 FPS suffers from the issues mentioned above, and I haven't been able to fix it so far myself. Maybe it's on me for relying on a 40-year-old display server for any of this, but the 15-year-old one (which works just fine for the video playback stuff) has that mouse lag issue on this specific hardware, so...

Checking in with

sudo intel_gpu_top

while playing back such content does not seem to indicate that this is a matter of pushing the GPU a bit too hard (but what *was* was playing 1080p60 in non-fullscreen with a specific compositor and xorg options combination, iirc it involved picom's glx or maybe egl backend, works fine now), so this is (probably) something other than that specifically.

Is it possible to fix either one of the issues mentioned above? I haven't been able to find much on both of these but the first one is exceptionally irritating because most reported cases of this seem to be with either Nvidia cards or Raspberry Pis... but this is Intel graphics... but maybe it's too old... who knows at this point. Fixing the second one would be neat too because that would mean that my DE options would basically be "everything that has an X11 session" (except GNOME, that one is never an option, at least on this kind of hardware, I mean some folks claim to have gotten it to run reasonably well enough on even older machines but my definition of "reasonably well enough" is substantially different from most others), but...

Any help would be much appreciated.

Last edited by why_do_i_need_a_username (2024-09-04 15:13:08)

V1del · 2024-08-31 22:15:53

Most of this sounds like you're not actually using the GPU in the first place, I have a skylake (afaik more or less same GPU generation) that has none of these issues. What output do you get from

glxinfo -B
sudo journalctl -b

why_do_i_need_a_username · 2024-09-01 18:30:47

`glxinfo -B`:

name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel (0x8086)
    Device: Mesa Intel(R) UHD Graphics 620 (KBL GT2) (0x5917)
    Version: 24.1.6
    Accelerated: yes
    Video memory: 7935MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) UHD Graphics 620 (KBL GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.1.6-arch1.1
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.1.6-arch1.1
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 24.1.6-arch1.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

`journalctl -b`: https://web.archive.org/web/20240902111 … ee/p/P9YH7

I've managed to get Xorg to run a *bit better* when it comes to video playback stuff on a secondary install on an external drive, 60 and 30 FPS video work "fine" with the caveat that there's a singular frame drop roughly every 2 minutes, though imo that's more of a "X is ancient and really shouldn't be used on desktops anymore" type of issue than anything actually solvable by myself tbh. That, or it's an issue with `xf86-video-intel`, which is allegedly "basically unmaintained" and also not at all recommended for hardware just slightly newer than this... the problem is that the alternative (well, excluding Wayland, which... I'll get to that one), `modesetting`, is even worse (because Vsync jitter or something, and also I've never gotten 60 FPS video to play smoothly with it), so I think (for now, at least, some of the performance stuff might actually be down to picom being sort of infamous for being not great performance-wise, the problem is that there aren't that many other options, there *is* https://github.com/tycho-kirchner/fastcompmgr and `xcompmgr` can still be had from the repos but most of the other compositors are DE-specific, they *can* be run on their own but I don't quite think I'd like to bother with that given that they're usually also WMs and I'd like to choose that part myself so...) this is as good as I'll get of an experience on here.

As for Wayland, the cursor lag thing is irritating enough that I'm not even considering it an option at this point. This happens on *everything* (except possibly GNOME when started with a certain environment variable, haven't looked into it that much yet) that I've tried, as in, "it happens on all distros", which makes sense because if this is a kernel issue, then everything with "Linux" in the name will be affected by it, if it's related to the protocol itself, same thing, and if it's something that all the compositors are affected by because they're all doing the same messed up stuff in their code, again, everything that uses those compositors will be affected by this. A lot of the mentions of similar stuff seem to mention "atomic modesetting" or something like that, though I'm not entirely convinced this is the whole story since my previous laptop (11th gen Intel, iGPU only; yes, I *did* "up"grade to an older machine from a newer one, that thing felt like what can best be described as "manufactured e-waste" so I'd still consider it an upgrade despite this nonsense) had no such issue (if it did, I would have noticed it immediately after starting a wayland session on it, I used Plasma Wayland (5.27) on there for a quite while and GNOME Wayland (before switching to the X11 session for... reasons) before that so I would have spotted it at one point or another). Too bad I don't have the other laptop anymore, sold it before buying this.

I have a feeling that the Wayland stuff happens simply because this iGPU is too old for Intel and/or kernel devs to give a damn about it, which is apparently a common-ish theme with `i915` (its kernel driver)...

I'm not sure how well it runs for you compared to how it does for me (not sure if you're running Wayland or X11 and what specific iGPU you have, I've seen at least one github/lab issue related to Linux graphics stuff where some sort of problem happened on machines with this general "flavor" of CPU+iGPU but then someone came in and said that they have such a device themselves and haven't been able to replicate it), so I may end up leaving it at this for now. Hopefully the Wayland input lag thing will get better because the video stuff I'm having issues with on X11 "Just Works[tm]" on Wayland so...

Last edited by why_do_i_need_a_username (2024-09-02 11:17:55)

seth · 2024-09-01 21:59:45

1. Wayland cursor input lag:

What "wayland" (which specific compositor)?
Same w/ https://wiki.archlinux.org/title/Sway#No_visible_cursor ?

if it wasn't for the fact that I seemingly can't get 30 FPS video to play smoothly under it … 30 FPS drops frames (or at least microstutters frequently) with both of those

Please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General
Also the output of "xrandr -q" and "mpv some_30fps_porn.mp4"
Also test the behavior of "mpv -vo=gpu --video-sync=display-resample some_30fps_porn.mp4" without picom or any other compositor active.

Last edited by seth (2024-09-01 21:59:56)

why_do_i_need_a_username · 2024-09-02 17:48:14

What "wayland" (which specific compositor)?

All (or most, there might be exceptions which I haven't investigated) of them. Everything wlroots-based does it (sway certainly does, labwc as well since that's what I tried daily driving and where I noticed it initially, wayfire too I think), so does `kwin_wayland` (only had kwin itself running, wasn't an entire KDE session), and *possibly* GNOME (mutter) as well, at least it felt like it from when I was booted into a Fedora (40) live image (which uses Wayland by default, at least it said the session was the Wayland one in the settings app thing that GNOME has), though it did feel *less* delayed there than with the others.... maybe, could have been just me imagining it. I'd have to install to disk (and make sure the GNOME on Xorg session is there as well so I can switch between Wayland and X11 to compare on the fly) to verify that though.

Same w/ https://wiki.archlinux.org/title/Sway#No_visible_cursor ?

Yes, I've actually tried that very `WLR_NO_HARDWARE_CURSORS=1` environment variable already with sway (and also labwc because there was an issue on their github from long, long ago where somebody told someone else to run it with that to solve... something, not sure what that something was, so at least I knew that it was supposed to be able to take such a variable and behave differently somehow) since some folks have mentioned that doing so helped with their pointer lag issues (and on some hardware it's basically mandatory, non-RPi SBCs mostly), which didn't help anything for me specifically...

For reference, this exhibits itself as a... ~0.2s? maybe less, maybe more? (I tried capturing it with my phone's "slow motion" camera mode but that footage looks so bad (washed out colors and insanely low resolution) that I basically regard it as useless, and screen record is not an option because from what I've tried and seen from other people also doing Linux/Wayland screen recording, the cursor specifically gets affected) delay between bringing your finger to and starting to drag it across the touchpad and something actually happening with the cursor on screen. It's *less* noticeable with a dedicated mouse (the one I currently use is wireless so there's an inherent delay but I was kinda able to replicate it with a wired one as well... kinda), but it still didn't feel like the movement was *instantaneous*, necessarily. I'd have to look into faking mouse movement in software under both Xorg (seems straightforward enough, there's `xdotool` or something for that) and Wayland (for the latter one, I'd probably attempt doing so with something wlroots-based or at least nice enough to offer more protocols (mostly `wlr-*` stuff) than just than the bare minimum to be able to call itself a "Wayland" compositor (which is basically what mutter does, was never able to do e.g. automatic mouse hiding with it, so I'm not going to pursue that option)) to make sure that it's not just a touchpad thing, as I *might* have been imagining the lag with an actual mouse, and because touchpads on Linux are... a weird kind of fun to be dealing with (temporarily had a T14 Gen2 AMD before this T480 that I returned (partially, there was another reason for returning it that I'm not going to disclose here for now) due to the touchpad not being able to talk to the kernel over its native (Intertouch RMI something) bus and having to fall back to PS/2 which made two-finger gestures awful to use, the polling rate would cut in half for every additional finger you added, though that was caused by AMD breaking something something SMBus on that gen of chip under Linux instead of the *usual* touchpad issues), so I'd like to eventually isolate that issue if that's what causing it. If it *is* the touchpad though, I'd still just use Xorg anyway because I use the touchpad heavily and it feels *borderline insufferable* under all the Wayland stuff I've tried, and for me, that's a big enough reason to just... not bother with it on this machine.

As for X11, I've just so managed to get it to play both 30 and 60 FPS pretty well with the following xorg.conf.d/20-intel.conf:

Section "Device"
  Identifier "Intel Graphics"
  Driver "intel"
  Option "AccelMethod" "sna"
  Option "VSync" "true"
  Option "TearFree" "true"
  Option "TripleBuffer" "true"
  Option "SwapbuffersWait" "false"
EndSection

Instead of `picom`, I'm using `fastcompmgr` for this, which would be ok if it wasn't for the fact that it makes Firefox scrolling lag every so often, which... no. I like my smooth (smooth as in smooth touchpad scrolling *and* as in "no screen tearing/general lag when it's animating the transition from one line to another") scrolling, thankyouverymuch. (yes, I already tried a bunch of `about:config` options to attempt making this better but nope, at least I already did before this) Not closing this yet because of this (and also because I'd like to solve the Wayland stuff too because getting that solved would make my life substantially easier since video playback has usually "Worked Reasonably Well Enough For Me To Not Want To F With It[TM]" under it (except on GNOME because it's way too overweight for any of the hardware that I've had a chance to get my hands on so far, except for maybe the aforementioned T14 G2 AMD but obviously I don't have that thing anymore), but that cursor lag stuff all looks very "deep down" to me so that might not quite be solvable).

Here's the Xorg log and for my main (`t480`) install: https://paste.ee/p/ENR8I
...and here it is for the secondary (`arch-throwaway`) one mentioned in the post before yours: https://paste.ee/p/BxDyQ

`xrandr -q`:

Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 310mm x 170mm
   1920x1080     60.01*+  59.93  
   1680x1050     59.88  
   1400x1050     59.98  
   1600x900      60.00    59.95    59.82  
   1280x1024     60.02  
   1400x900      59.96    59.88  
   1280x960      60.00  
   1368x768      60.00    59.88    59.85  
   1280x800      59.81    59.91  
   1280x720      59.86    60.00    59.74  
   1024x768      60.00  
   1024x576      60.00    59.90    59.82  
   960x540       60.00    59.63    59.82  
   800x600       60.32    56.25  
   864x486       60.00    59.92    59.57  
   640x480       59.94  
   720x405       59.51    60.00    58.99  
   640x360       59.84    59.32    60.00  
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

if it wasn't for the fact that I seemingly can't get 30 FPS video to play smoothly under it … 30 FPS drops frames (or at least microstutters frequently) with both of those

That's not necessarily the case anymore right now, rn it's only "somewhat terrible and in ways mostly unrelated to video playback", not "completely terrible".

The 30 FPS test video that I use (https://www.youtube.com/watch?v=-Ht8EIAOrj8) is only 30 seconds long (I found another one which is 5-ish minutes and that could be used for testing this but it's 29.something instead of 30.000 and I want 30 exactly), so I have `mpv` loop it for me (cli flag `--loop=yes`). Here's what the output of `mpv /the/path/to/my/30/fps/test/video.mp4` (without a config file for mpv or anything) looks like:

 (+) Video --vid=1 (*) (h264 1920x1080 30.000fps)
 (+) Audio --aid=1 (*) (aac 2ch 44100Hz)
AO: [pipewire] 44100Hz stereo 2ch floatp
VO: [gpu] 1920x1080 yuv420p
AV: 00:00:29 / 00:00:30 (100%) A-V:  0.000
Exiting... (End of file)

Doing that with `--vo=gpu --video-sync=display-resample` (didn't know that that second flag was a thing, seems neat) and without fastcompmgr running works just fine but that's with `xf86-video-intel`'s "comfort features" enabled (`TearFree` and all that) so I'm not sure how fair of a test that is.

As for picom... I'd like to get it working someday for this but I haven't been able to do that so far. To get 60fps playing smoothly, I've had to use its `xrender` backend, but then 30fps plays like trash, which is what got me to start this thread initially. Pretty much everybody will tell you that `xrender` is terrible and that it doesn't even do stuff like vsync properly (probably the reason why it sucks at rendering non-framerate-matching video in the first place tbh) and that you really should be using `glx` instead, which I've done, and... it's not great either. Both 60 and 30fps drop frames ~1.5-2 minutes into playback, moving windows feels terrible (no tearing or anything but it's just... ehhh...), and it's just generally not particularly great for me on this hardware. There's barely any other compositors out there anyway (the aforementioned `fastcompmgr` is a fork of an old `compton` version which itself became `picom` later on, and there are the DE compositors like mutter and kwin_x11 but those are also WMs and as stated in my last post, I'd like to choose my WM myself, there might be a way to disable the WM part in at least one of those but this whole "just use a DE compositor) option is kinda a "last resort" type of thing anyway so I'm not sure I'd like to research that for now), so... There are some picom forks on the AUR (i.e. `picom-ftlabs-git`) but those are mostly related to stuff like animations so basically the opposite of what I'm looking for (pushing the hardware even harder with animation BS vs putting less load on it). Sorry if all this was too long.

Last edited by why_do_i_need_a_username (2024-09-02 19:34:12)

why_do_i_need_a_username · 2024-09-03 16:12:40

Just found out that DRI was broken the whole time on the mentioned secondary install when trying to start `mutter --x11` or something like that. Added this:

  Option "DRI" "iris"

to my `/etc/X11/xorg.conf.d/20-intel.conf`. Also made Firefox scrolling somewhat (trying not to overrate this) better by toggling `gfx.egl.prefer-gles.enabled` in `about:config` from `true` to `false` because I had set it to `true` at some point when trying to make it run better, ironically. Also set `gfx.x11-egl.force-enabled` to `true` which *might* have helped... might... not sure about that yet.

Closing this as I think the wayland thing should get its own post and doesn't belong in this part of the forum anyway.

Last edited by why_do_i_need_a_username (2024-09-04 15:03:17)

Arch Linux

#1 2024-08-31 07:26:04

[SOLVED-ish] UHD 620 Xorg 30 FPS Video Issues

#2 2024-08-31 22:15:53

Re: [SOLVED-ish] UHD 620 Xorg 30 FPS Video Issues

#3 2024-09-01 18:30:47

Re: [SOLVED-ish] UHD 620 Xorg 30 FPS Video Issues

#4 2024-09-01 21:59:45

Re: [SOLVED-ish] UHD 620 Xorg 30 FPS Video Issues

#5 2024-09-02 17:48:14

Re: [SOLVED-ish] UHD 620 Xorg 30 FPS Video Issues

#6 2024-09-03 16:12:40

Re: [SOLVED-ish] UHD 620 Xorg 30 FPS Video Issues

Board footer