mpv drops frames every 10 seconds on Xorg modesetting driver

why_do_i_need_a_username · 2024-10-20 18:58:48

Title explains the issue. When playing a video in mpv under Xorg (currently can't use Wayland because of this) and with the modesetting driver (xf86-video-intel is fine) on my ThinkPad T480 (non-dGPU, Intel UHD 620), it drops frames every ~10 seconds, for as long as the video is running. For example, I have a 1 minute long video (1080p60) for testing exactly this kind of thing, and it drops frames at 00:00:10, 00:00:20, 00:00:30, 00:00:40, and so on and so on. Literally nothing seems to fix this, including:

mpv CLI flags I tried: --video-sync=display-resample, --x11-bypass-compositor=yes, --opengl-es=yes, and probably others
xorg.conf options: most of the stuff mentioned here: https://gitlab.freedesktop.org/xorg/xse … te_2298152
swapping out mesa for mesa-amber and using i965 instead of iris

And probably other stuff I tried, but which I can't quite recall anymore.
My mpv.conf looks like this:

hwdec=vaapi
vo=gpu-next
ao=pulse

For reference, my setup is Arch with xfce and xfwm4's compsitor with glx vblank_mode in xfconf (at the moment, now back on the intel driver; this probably happens with everything, I think I even tried it with picom and it still did it), with me using xorg-server-git to test modesetting and xorg-server for intel (because xf86-video-intel refuses to build properly anymore, I tried and it just kept leaking memory indefinitely until it got killed by (presumably) the OOM killer, so I formatted an entire 128GB external drive as swapspace, activated it, tried again, left it there for 6+ hours and it still wouldn't finish the build... in comparison the Xorg server basically builds pretty much instantly, so I'm pretty much stuck with the prebuilt binary in Arch's repos and I can't use it on the -git server because there's mismatching versions and stuff, I think there's a flag to bypass that check but still).
I know that Xorg is pretty much dead, but still. Is there anything I can do about this, or am I kinda just stuck with the intel driver (which is basically unmaintained, as evidenced by the fact that it doesn't build properly anymore)? I'd like to stop using it because I think I have higher input lag (when typing and stuff) with it than with modesetting, but the mpv thing basically prevents me from doing that. Anything I can do about this?
Thanks in advance.

seth · 2024-10-20 20:30:44

Drops how many frames, one?
Same for a 360p@60?
What about a 30fps video? One frame every 20 seconds?
What if you disable the compositor?
Same for ao=null ?

When using xf86-video-intel (and mesa, not mesa-amber) do you specify the DRI as iris?
Does glxgears indicate the output is synced on xf86-video-intel (basically, post xorg logs for both setups - and also the output of "xrandr -q")

Do youhave unrelated issues w/ xf86-video-intel? Why aren't you using it instead?

why_do_i_need_a_username · 2024-10-21 07:07:19

Drops how many frames, one?

Three to four, actually:

[user@t480 Desktop]$ mpv ~/LCD\ display\ motion\ test\ 60fps\ \[vigX3H7WX5Q].webm --video-sync=display-resample
● Video  --vid=1  --vlang=eng  (vp9 1920x1080 60 fps) [default]
● Audio  --aid=1  --alang=eng  (opus 2ch 48000 Hz) [default]
Using hardware decoding (vaapi).
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu-next] 1920x1080 vaapi[nv12]
AV: 00:00:10 / 00:00:59 (17%) A-V:  0.018 DS: 1.01/2 Dropped: 4

Same for a 360p@30?

Not sure. 30FPS playback just kinda seems generally jittery in mpv with modesetting, however this is how it went:

[user@t480 Desktop]$ mpv ./30\ FPS\ Judder\ Test\ \[t7pN9xNudJg\].mp4 --video-sync=display-resample
● Video  --vid=1  (h264 640x360 30 fps) [default]
● Audio  --aid=1  (aac 2ch 44100 Hz 128 kbps) [default]
Using hardware decoding (vaapi).
AO: [pulse] 44100Hz stereo 2ch float
VO: [gpu-next] 640x360 vaapi[nv12]
(Paused) AV: 00:00:10 / 00:04:51 (4%) A-V:  0.001 DS: 2/12 Dropped: 9

It dropped 8 frames or so when playback begun (which doesn't happen with the 1080p60 one), and then after 10 seconds, it dropped another one. Single frames this time. Sometimes it doesn't increment the "Dropped: " counter but the "DS: " bit goes wild for a bit and the drop/jitter is visible, and it happens every 10 seconds (not 20).

What if you disable the compositor?

This is a bit weird to do since the compositor is what makes the frames actually look tolerable-ish in the first place (i.e. gets rid of the screen tearing, unless "TearFree" is on in xorg.conf), but here it is anyway (without TearFree on, with that option only being available in xorg-server-git for modesetting):

360p@30:

[user@t480 Desktop]$ mpv ./30\ FPS\ Judder\ Test\ \[t7pN9xNudJg\].mp4 --video-sync=display-resample
● Video  --vid=1  (h264 640x360 30 fps) [default]
● Audio  --aid=1  (aac 2ch 44100 Hz 128 kbps) [default]
Using hardware decoding (vaapi).
AO: [pulse] 44100Hz stereo 2ch float
VO: [gpu-next] 640x360 vaapi[nv12]
(Paused) AV: 00:00:10 / 00:04:51 (4%) A-V:  0.000 DS: 2/12 Dropped: 20

It drops a lot more frames at the beginning (in fact, in some runs it even gave me this warning:

Audio/Video desynchronisation detected! Possible reasons include too slow
hardware, temporary CPU spikes, broken drivers, and broken files. Audio
position will not match to the video (see A-V status field).
Consider trying `--profile=fast` and/or `--hwdec=auto-safe` as they may help

), but afterwards it goes back to the same "drops every 10 seconds" behavior as before.

The amount of dropped frames at the beginning is somewhere between 18 (least that I've seen) to 45 (most), with me pausing the video and copying the terminal output right after the first drop.

1080p@30:

[user@t480 Desktop]$ mpv ~/30\ FPS\ Judder\ Test\ \[t7pN9xNudJg].mp4 --video-sync=display-resample
● Video  --vid=1               (h264 1920x1080 30 fps) [default]
● Audio  --aid=1  --alang=eng  (aac 2ch 48000 Hz 2 kbps) [default]
Using hardware decoding (vaapi).
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu-next] 1920x1080 vaapi[nv12]
(Paused) AV: 00:00:10 / 00:04:51 (4%) A-V: -0.003 DS: 2/2 Dropped: 1

This one is a lot better behaved, since it doesn't drop the frames initially, and the same "sometimes it doesn't count the drops as drops" behavior happens here too.

1080p@60:

[user@t480 Desktop]$ mpv ~/LCD\ display\ motion\ test\ 60fps\ \[vigX3H7WX5Q].webm --video-sync=display-resample
● Video  --vid=1  --vlang=eng  (vp9 1920x1080 60 fps) [default]
● Audio  --aid=1  --alang=eng  (opus 2ch 48000 Hz) [default]
Using hardware decoding (vaapi).
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu-next] 1920x1080 vaapi[nv12]
AV: 00:00:11 / 00:00:59 (19%) A-V: -0.015 DS: 1.01/0

This one doesn't drop any frames at the beginning either, and it doesn't always count the drops as drops either. It looks like this after 31 seconds of running:

[user@t480 Desktop]$ mpv ~/LCD\ display\ motion\ test\ 60fps\ \[vigX3H7WX5Q].webm --video-sync=display-resample
● Video  --vid=1  --vlang=eng  (vp9 1920x1080 60 fps) [default]
● Audio  --aid=1  --alang=eng  (opus 2ch 48000 Hz) [default]
Using hardware decoding (vaapi).
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu-next] 1920x1080 vaapi[nv12]
(Paused) AV: 00:00:31 / 00:00:59 (52%) A-V: -0.003 DS: 1/2 Dropped: 2

Same for ao=null? Reenabling the compositor for this, and yes, it does indeed behave the same:

[user@t480 Desktop]$ mpv ~/LCD\ display\ motion\ test\ 60fps\ \[vigX3H7WX5Q].webm --video-sync=display-resample --ao=null
● Video  --vid=1  --vlang=eng  (vp9 1920x1080 60 fps) [default]
● Audio  --aid=1  --alang=eng  (opus 2ch 48000 Hz) [default]
Using hardware decoding (vaapi).
AO: [null] 48000Hz stereo 2ch floatp
VO: [gpu-next] 1920x1080 vaapi[nv12]
AV: 00:00:10 / 00:00:59 (18%) A-V: -0.013 DS: 0.99/2 Dropped: 1

When using xf86-video-intel (and mesa, not mesa-amber) do you specify the DRI as iris?

Yes. I had actually made the mistake of not having done that when making an earlier post, however that has since been fixed:

[user@t480 ~]$ cat /etc/X11/xorg.conf.d/20-intel.conf 
Section "Device"
  Identifier "Intel Graphics"
  Driver "intel"
  Option "AccelMethod" "sna"
  Option "DRI" "iris"
  Option "VSync" "false"
  Option "TearFree" "false"
  Option "TripleBuffer" "true"
  Option "SwapbuffersWait" "true"
EndSection

I change those last 4 options (VSync, TearFree,...) relatively frequently to see if there's any better set of config options when it comes to both frame drops and input latency, so don't expect that those are always set the way they are here.

Does glxgears indicate the output is synced on xf86-video-intel (basically, post xorg logs for both setups - and also the output of "xrandr -q")

Now this one's interesting, because when running glxgears on modesetting, it locks up at the beginning for ~1s and then keeps going:

[user@t480 Desktop]$ glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
# locks up here, stays there for ~1s
379 frames in 5.0 seconds = 75.642 FPS # unfreezes here
301 frames in 5.0 seconds = 60.009 FPS # keeps going as normal

Or, in other words, something is broken. Might be vsync that's broken because this issue exists, but whatever. Been open for 4 years at that.

glxgears on xf86-video-intel works just fine. It freezes for a fraction of a second at the beginning and generates a lot more frames the first time round than later but that's probably just expected behavior. It's a lot worse with modesetting.

The logs:

/var/log/Xorg.0.log for xf86-video-intel

/var/log/Xorg.0.log for modesetting

xrandr -q for xf86-video-intel

xrandr -q for modesetting

Do youhave unrelated issues w/ xf86-video-intel? Why aren't you using it instead?

I think I have slightly better latency with the modesetting driver, however I'm not quite sure about that and that "lower latency" (if it exists; most of my latency reduction-related shenanigans have been mostly imaginary/placebo-based, though some stuff really is awful for latency, the picom compositor for one) may as well come from the fact that something is broken about it, so... Also, the fact that it doesn't build properly is somewhat unsettling and I'd like to run a driver that actually compiles as intended in the present day, at least I haven't been able to get xf86-video-intel to build from source (described in OP). Not that that's necessarily how it's going to be forever, it's just that the driver is kinda generally dead anyway and I'd rather not use it... though it does work just fine.

Also, there's a lot of people going around saying that "there's no reason to use the non-modesetting drivers anymore", and I'd like that to be the case, though obviously that doesn't appear to be the case yet (if it ever will be).

Last edited by why_do_i_need_a_username (2024-10-21 08:23:14)

seth · 2024-10-21 13:44:32

i915.enable_psr=1 i915.enable_dc=1 i915.enable_fbc=0 i915.enable_rc6=1 i915.semaphores=1 i915.disable_power_well=1 i915.enable_guc=3

How much of that is mitigational effort for the issue at hand, and what's just there "because"?
https://patchwork.kernel.org/project/in … son.co.uk/

[ 11.306] (**) intel(0): Option "VSync" "false"
[ 11.306] (**) intel(0): Option "SwapbuffersWait" "true"
[ 11.306] (**) intel(0): Option "TripleBuffer" "true"
[ 11.306] (**) intel(0): Option "TearFree" "false"
[ 11.270] (**) Option "BlankTime" "0"

Ok, what if you skip all that? Does the intel driver behave more like the modesetting one?

--video-sync=display-resample

Is the switch a mandatory precondition or do you drop frames w/o it as well?

Now this one's interesting, because when running glxgears on modesetting, it locks up at the beginning for ~1s and then keeps going:

Smells power saving related.
Do you get a run-up for

vblank_mode=0 glxgears

Does the behavior differ on the intel driver?

So for strategy: you're throwing too much (and random) shit against the wall at the same time.
"Unconfigure" the system and compare the behavior (w/o resampling)
If that turns out to yield equal outcome, you can start to figure what parameter makes a crucial difference.

Ftr

modesetting:
1920x1080 60.01*+ 60.01
intel:
1920x1080 60.01*+ 59.93

despite that

modeset(0): Modeline "1920x1080"x60.0  138.80  1920 1944 1992 2080  1080 1083 1095 1112 -hsync -vsync (66.7 kHz eP)
modeset(0): Modeline "1920x1080"x60.0  138.68  1920 1968 2000 2080  1080 1083 1088 1111 +hsync -vsync (66.7 kHz d)
  intel(0): Modeline "1920x1080"x0.0   138.80  1920 1944 1992 2080  1080 1083 1095 1112 -hsync -vsync (66.7 kHz eP)

intel and modesetting seem to use the same modeline.

The general trajectory is towards the modesetting driver, yes. I was mainly concerned that you're avoiding the intel driver because of an undisclosed misbehavior.

seth · 2024-10-21 14:03:39

Addendum: do not run picom for any of these tests.
The compositor adds a whole new slew of variables to the problem.

why_do_i_need_a_username · 2024-10-21 17:34:50

I think I put the "power saving" kernel flags there out of desperation when trying to debug some other thing (not sure if it's been fixed by that or by something else, can't quite remember what it was), knew that some stuff could cause system hangs but didn't know that enable_rc6 could do that specifically, thanks for that. I think I just threw some stuff from this there at some point, then later on messed around with the values out of (again) desperation, and who knows what else happened.

Removed the offending kernel flags and modesetting still behaves the same. Sorry about that. Same thing with the glxgears lockup bit.

With the intel driver, the video drops out a bunch of frames around the 40 second mark without the resample flag, fine with it being there. However, playing the video as a local file in Firefox (which is where I actually consume most of my media so I care about this one more than mpv, mpv is really just for testing for me) results in really, really "not great" playback (frames drop out every 3-6-ish seconds), happens with the flags there too so it's probably just that the composition setup I'm running at the moment (which really gets created by way of me going ham at /etc/X11/xorg.conf.d/20-intel.conf or ~/.config/picom/picom.conf (if I'm using that compositor at that moment, which right now I'm not) whenever a frame drops out in whatever I'm watching, problem is, I haven't watched anything video-based on this machine seriously for at least a few days and messed with some stuff inbetween that). However, mpv fares better without the resample flag thing with the kernel options being there, so the kernel flags do kinda help, even if they're... not really recommended.

Also, "vblank_mode=0 glxgears" behaves like this: starts immediately (both intel and modesetting), generates a ton of frames, fans spin up within ~2-3 seconds, machine starts emitting audible coil whine. Not surprising since the difference is 60 fps vs 8000-ish fps.

As for where I got that mpv resample thing ("video-sync=display-resample"), that was something I got from here, seems to work like pure magic on other setups which otherwise drop frames but not here. Same behavior happens without it though.

Removing the config for the modesetting driver besides the bare minimum (really just telling it to use the modesetting driver, full config looks like this btw), same frame-dropping behavior as previously. Swapping out xorg-server-git for the binary build in the repos, there's a giant tearline roughly 10% from the top, most likely due to the fact that xorg-server-git's modesetting defaults to TearFree being on while the older stable release has no TearFree option to begin with. Replacing xfwm4's compositor with picom does not help, both with my old config and the one at /etc/xdg/picom.conf (which has border transparency and fade animations and other glowy shit I don't care about), switching back to xfwm4 and setting vblank_mode to "xpresent" (from "glx") does not help either. I'm sure there's a solution to this since this is one of the most "conventional" setups for Xorg (as in, there's virtually no setup) and some desktops probably just have this working out of the box but really I don't feel like dealing with this shit right now and I'd much rather be running something Wayland-based but can't because of the goddamn cursor lag on both of the (modern-ish; I have two older machines as well) laptops I own...

Testing it without picom (or I suppose any compositor) as you asked, didn't notice the second message until now and I'm not rewriting the previous stuff, so here's all the tests without any compositor running (xf86-video-intel is being tested here without (at least iirc) vsync and TearFree):

glxgears, intel: no lockup at beginning

glxgears, modesetting git, TearFree+VSync on: the "1 second lockup" behavior happens here

glxgears, modesetting git, TearFree+VSync off: same

glxgears, modesetting stable: no lockup at beginning

vblank_mode=0 glxgears, intel: same as described up top.

vblank_mode=0 glxgears, modesetting git, TearFree+VSync on: same, higher average frame rate (9000-9500-ish compared to the one below)

vblank_mode=0 glxgears, modesetting git, TearFree+VSync off: same (around 8000-8400 FPS)

vblank_mode=0 glxgears, modesetting stable: same (don't remember the FPS)

mpv 1080p60, no resample, intel: no explicit frame drops but (because no compositor) giant tearline that starts up top and progressively keeps going lower and lower as the video plays

mpv 1080p60, video-sync=display-resample, intel: identical, at least pretty sure

mpv 1080p60, no resample, modesetting git, TearFree+VSync on: frames drop out every 10 seconds as described previously

mpv 1080p60, no resample, modesetting git, TearFree off, VSync on: same as on intel, no "frame drops every 10s" as with TearFree

mpv 1080p60, no resample, modesetting git, TearFree+VSync off: same as on intel

mpv 1080p60, no resample, modesetting stable: same

(Didn't try 30fps, sorry about that, and I didn't run all of the tests at large anyway because I don't want to do that right now)

Must mention that at some point while doing this, I ran into a video lockup issue related to pulseaudio:

[user@t480 Desktop]$ mpv ~/LCD\ display\ motion\ test\ 60fps\ \[vigX3H7WX5Q].webm 
● Video  --vid=1  --vlang=eng  (vp9 1920x1080 60 fps) [default]
● Audio  --aid=1  --alang=eng  (opus 2ch 48000 Hz) [default]
Using hardware decoding (vaapi).
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu-next] 1920x1080 vaapi[nv12]
[ao/pulse] pa_stream_update_timing_info() failed: Connection terminated
[ao/pulse] pa_stream_update_timing_info() failed: Connection terminated
[ao/pulse] pa_stream_update_timing_info() failed: Connection terminated
[ao/pulse] pa_stream_cork() failed: Connection terminated
[ao/pulse] pa_stream_flush() failed: Connection terminated
AO: [pulse] 48000Hz stereo 2ch float
AV: 00:00:24 / 00:00:59 (41%) A-V:  0.000
Exiting... (Quit)

I actually ran into lockups when testing Firefox a few weeks ago and thought it was caused by whichever compositor I was running but knowing that it was actually pulse at fault all along... yeah

Edit: Must mention that this only happens very rarely and usually right after logging into the desktop, and outside of that, it's very much a "once in a full moon" kinda thing

And yes, I am indeed running pulse and not pipewire, figured that since I'm not running Wayland and don't need it for screenshare and whatever, I'd run the objectively worse sound server simply because pipewire has this issue where if you watch 60+ FPS content in a browser (at least Firefox which doesn't support pipewire for audio natively, not sure about chromium but I think it's affected too), it'll drop frames due to pipewire-pulse adding overhead or something, has been happening for as long I've known pipewire existed.

pulseaudio does suck but unwatchable 60fps in web browsers... yeah no thanks. Even if I was running Wayland, I'd probably just set up wireplumber to have it be a screensharing and camera service only and have pulse handle audio (something I've done before, on Fedora of all distros at that). mpv is great and all but sometimes I just don't want to watch videos in a dedicated app, so nope.

Smells power saving related.

Not sure if this is relevant but I'll mention that I am running tlp, specifically with this config (not human-written, created using tlpui GUI). Mentioning it because I have some (tbh absolutely crazy) power settings for the iGPU set in there, possibly that? I do realize that some of these settings are probably dangerous long-term, and I absolutely intend to change them once I get this stuff actually working properly.

Also, since this is a T480, I'll also say that yes, I do indeed have throttled set up, if that's relevant.

And yes, I am very much "throwing random shit against the wall at the same time", I apologize for that. I basically consider myself to be the embodiment of the XY problem at this point so I don't expect too much from myself anyway.

Last edited by why_do_i_need_a_username (2024-10-21 18:31:47)

seth · 2024-10-23 13:15:44

So for recap of that WOT: it's basically down to using the TearFree feature on xorg-xserver-git.
The intel driver has a TearFree setting as well, https://man.archlinux.org/man/extra/xf8 … #Option~11
Does it cause the same frame-drops on the released or the git xorg server?

As for browser video, that's an issue in and by itself.
https://wiki.archlinux.org/title/Firefo … celeration
Reg. PW ./. PA
https://wiki.archlinux.org/title/Firefo … a_playback (make sure to not use PW and PA but pipewire-pulse)
https://wiki.archlinux.org/title/PipeWi … ot_working (ignore the context)

why_do_i_need_a_username · 2024-10-24 09:07:23

it's basically down to using the TearFree feature on xorg-xserver-git.

Yes. I actually ran into this earlier, thought it sucked, stopped using it, then decided to use it again for other reasons, thought it sucked (again), but this time decided to post about it online in hopes that someone else would have ran into this and fixed it somehow... oh well.

The intel driver has a TearFree setting as well

I know, in fact I've been using it all along and the tests I did all used it, I just forgot to mention it and didn't do them without TearFree in addition to with it because I really didn't want to do that again so...

Does it cause the same frame-drops on the released or the git xorg server?

Not sure what you're referring to, if you're referring to the intel driver then I can only test it on the release one, any attempts I've tried to build it from source for the git server have failed (there is an AUR package for it but it fails due to compiler flags that don't work anymore, resulting in a "C compiler cannot create executables" error or something like that during the configure script, removing them from the PKGBUILD gets me further and it looks promising but then it stops moving at some point (don't remember where) and starts leaking memory indefinitely; see the original post for more information), and if you mean modesetting then the release version doesn't have the TearFree option since it predates it getting added to the modesetting driver so that can't be tested properly.

I could attempt testing xf86-video-intel with the prebuilt package in the repos and the -git server using the -ignoreABI flag for xorg (usually mentioned in relation to using ancient nvidia drivers on modern xorg but it seems to be a thing in xorg itself, not the nvidia drivers), but I don't feel like switching to the -git packages temporarily (for the nth time in the last 14 days) just to have it fail and having to revert to the stable build so nope.

As for browser video, that's an issue in and by itself.

I do have hardware video decoding in Firefox going (evidenced by playing a video in Firefox and then running intel-gpu-top), and the other links:

https://wiki.archlinux.org/title/Firefo … a_playback (make sure to not use PW and PA but pipewire-pulse) https://wiki.archlinux.org/title/PipeWi … ot_working (ignore the context)

seem to be irrelevant (though I could mess around with the stuff later), the actual issue is this, see the "happens on every distro as far as I know" part).

Clarification: I do actually have pipewire on my machine, but it's just there to make flatpak happy and the audio stuff is disabled, also wireplumber is not present, though if I really needed it to be there (for Wayland purposes and the like), there's a way around that; see this post of mine on the Fedora forums from a while back (specifically the thing about commenting out lines in the wireplumber config, also ignore the "create a script that prevents our config from being obliterated by the package manager" bit, that was just me not yet knowing I could put it in /etc/wireplumber/ without the risk of that happening, also I mistyped /usr/local/bin as /usr/bin/local there so...).

PA does suck but this is irritating enough that I'm willing to tolerate forcing the machine to keep running it anyway even though the Linux community as a whole (mostly) seems to consider the PW transition to be a done deal despite glaring issues like this. No thanks.

I'll probably attempt reinvestigating getting pipewire and Firefox to be happy with each other (I mean they do work together mostly fine thanks to pipewire-pulse but... the frame drops, man), or maybe I'll just wait it out until Mozilla adds native pipewire support to Firefox, which might never happen but they could also be forced into doing it later on so who knows.

Last edited by why_do_i_need_a_username (2024-10-24 09:11:52)

seth · 2024-11-04 14:16:08

referring to the intel driver then I can only test it on the release one, any attempts I've tried to build it from source for the git server have failed

Ok, this would remain a relevant test, feel free to upload the build log on 0x0.st - maybe it's an easy fix.

That aside: how does mpv behave on the released server + modesetting (no TearFree, though it's not available anyway) + resample + (syncing) picom?
(The compositor doing the syncing part to prevent tearing)

why_do_i_need_a_username · 2024-12-27 10:03:12

I know it's been a while, and you probably don't care about this anymore, but I'm leaving this here anyway (because it looks like Google and other search engines have already crawled this post and it shows up if you look related stuff up, so because of that) in case anybody stumbles upon this: `xf86-video-intel` *does* indeed build just fine in the modern day and age, UNLESS you try to build it against the `xorg-server-devel-git` headers, because there's a guy messing around with the Xorg server codebase big time, and there's a lot of missing variable names and whatnot if you attempt it (Xv related stuff comes up at first, and that's where it fails). Building it for the stable version works just fine though. The issue is basically just that there's build options in `/etc/makepkg.conf` that conflict with it, resulting in the "keeps leaking memory indefinitely" behavior I mentioned before.

What I've done to get it to compile was export `CFLAGS`, `CXXFLAGS`, `LDFLAGS` and `LTOFLAGS` as empty in the `PKGBUILD` for `xf86-video-intel-git`, which isn't really a good idea, but... yeah I really have no idea what I'm doing here, so...

What one should *actually* do is figure out which options make it build successfully while also not being completely unoptimized, but...

Last edited by why_do_i_need_a_username (2024-12-27 10:04:19)

Arch Linux

#1 2024-10-20 18:58:48

mpv drops frames every 10 seconds on Xorg modesetting driver

#2 2024-10-20 20:30:44

Re: mpv drops frames every 10 seconds on Xorg modesetting driver

#3 2024-10-21 07:07:19

Re: mpv drops frames every 10 seconds on Xorg modesetting driver

#4 2024-10-21 13:44:32

Re: mpv drops frames every 10 seconds on Xorg modesetting driver

#5 2024-10-21 14:03:39

Re: mpv drops frames every 10 seconds on Xorg modesetting driver

#6 2024-10-21 17:34:50

Re: mpv drops frames every 10 seconds on Xorg modesetting driver

#7 2024-10-23 13:15:44

Re: mpv drops frames every 10 seconds on Xorg modesetting driver

#8 2024-10-24 09:07:23

Re: mpv drops frames every 10 seconds on Xorg modesetting driver

#9 2024-11-04 14:16:08

Re: mpv drops frames every 10 seconds on Xorg modesetting driver

#10 2024-12-27 10:03:12

Re: mpv drops frames every 10 seconds on Xorg modesetting driver

Board footer