Hi, does anyone know how to enable TearFree (VSync) for xf86-video-modesetting? Regards
Somebody would have to implement TearFree support in the modesetting driver.
TearFree is an optional addition specific to the Intel SNA X driver. It is unlikely that it will be added to the modesetting driver. Compositors will solve the same problem - most users use compositors. If there is increased demand, particularly from a distribution to support this, please re-open the bug.
FWIW, the xf86-video-ati and xf86-video-amdgpu drivers also support TearFree. Also, a compositor can't prevent tearing in all cases, e.g. with rotated or otherwise transformed displays.
(In reply to Michel Dänzer from comment #3) > Also, a compositor can't prevent tearing in all cases, e.g. with rotated or > otherwise transformed displays. Thanks, reopening then. (In reply to Michel Dänzer from comment #3) > FWIW, the xf86-video-ati and xf86-video-amdgpu drivers also support TearFree. xf86-video-ati and xf86-video-amdgpu also use Glamor for 2D acceleration. So maybe the TearFree code from them can be borrowed for xf86-video-modesetting?
(In reply to N. W. from comment #4) > xf86-video-ati and xf86-video-amdgpu also use Glamor for 2D acceleration. > > So maybe the TearFree code from them can be borrowed for > xf86-video-modesetting? It probably could (it's mostly agnostic to the rendering method used).
Any update?
(In reply to Ben Widawsky from comment #2) > Compositors will > solve the same problem - most users use compositors. I can confirm that this is not always the case even if no transformations have been applied on the display. For example using the XFCE compositor, tearing artifacts will be present in the video whether sync to vertical blank is turned on or off. Turning the compositor off fixes tearing, but introduces other artifacts and isn't really a viable option anyway in this day and age. So a tear-free option in xf86-video-modesetting would indeed be a very welcome improvement.
(In reply to t.ambetarak from comment #7) > For example using the XFCE compositor, tearing artifacts will be present in the > video whether sync to vertical blank is turned on or off. That's a compositor (configuration) issue.
(In reply to Michel Dänzer from comment #8) > (In reply to t.ambetarak from comment #7) > > For example using the XFCE compositor, tearing artifacts will be present in the > > video whether sync to vertical blank is turned on or off. > > That's a compositor (configuration) issue. Actually, xfwm4 4.13.x (dev. version) supports either Xpresent or GL, but vsync in any version of xfwm4 prior to this was a (bad) joke.
This would be very helpful on tablets where changing screen orientation is common use case.
+1; a lot of tearing on rotated external lcd & modesetting. intel driver works ok, but it has problems on its own
Also, in many cases the compositors don't take care of fullscreen windows and, hence, even something like playing a video with totem (for example) shows this issue
The fullscreen tearing problem in Ubuntu/Unity/Compiz at least, is intentional. We "unredirect" fullscreen windows for maximum (gaming) performance. If you would prefer to avoid tearing in the fullscreen case (slightly lower performance) then you can disable the feature by adding a specific match for the app window in: ccsm > Composite > Unredirect Match or just disable it completely for all: ccsm > Composite > Unredirect Fullscreen Windows = OFF If you're using multiple monitors then you will also see desktop tearing on all but one of them. This is because compiz paints all the monitors simultaneously as a single window, and being a single swap operation can only sync correctly to one of them. In theory the solution for this is to set: ccsm > Composite > Force independent output painting = ON However I'm not sure how well that feature works in practice right now. Certainly this depends on the GL driver being very clever about knowing which monitor to sync to. I don't think that GLX/EGL provides sufficient flexibility for the compositor to be able to choose a monitor to sync to. So you'll probably still get tearing on secondary monitors, unless the driver implements some clever workaround for delaying/syncing the secondary scan-outs, like I imagine "TearFree" does (guessing). TL;DR - Avoiding tearing on secondary monitors in X11 is not a compositor problem because the compositor can't do it using GLX/EGL. It's a driver problem, or a display server problem. We made sure it never happened when we wrote Mir but that required direct access to KMS/DRM, which an X11 compositor does not have. P.S. As a minimum in Ubuntu/Unity/Compiz you should also check that the defaults for avoiding tearing in the single monitor case are still correctly set: ccsm > OpenGL > Sync To VBlank = ON ccsm > OpenGL > Always use buffer swapping = ON Certainly if you're seeing tearing in the single monitor case and those are already enabled, then it's a bug.
I am trying to work with a GPD pocket which is a device based on an Intel Cherry Trail SoC with a tablet screen attached. Rotation is necessary because the screen thinks left is up. The Intel driver with SNA does support TearFree, but it corrupts the display after some time (fixable for a short time by switching resolution with xrandr). So I am trying the modesetting driver by removing the xorg.conf.d fragment about the intel driver. It works, but tearing in Xfce (Xubuntu 17.10) is horrible. Moving through a menu where the lines are highlighted in some way really hurts the eye. Is there a decision to add TearFree to the modesetting driver?
Last I tested Xfce, it did indeed tear a lot. I think that's Xfce's fault and should be logged as a separate bug with that. I say it's Xfce's fault because I found it was tearing even with compositing enabled, and even with a single monitor.
I understand where you're coming from, but one cannot declare it a fault of XFCE when only select desktop environments and their wm and/or compositor hide the problem. Like XFCE's compositor isn't able to, neither is compton with forced vsync. xf86-video-intel's TearFree is the only reliable way right now. Also, if you use Weston long and hard enough, you can observe tearing with a Wayland compositor when tearing was one of the problems Wayland was supposed to fix once and for all.
(In reply to Carsten Mattner from comment #16) > if you use Weston long and hard enough, you can observe > tearing with a Wayland compositor when tearing was one of the problems > Wayland was supposed to fix once and for all. That is highly doubtful. (In reply to Carsten Mattner from comment #16) > neither is compton > with forced vsync. With the proper settings, Compton does not tear, even when you use it as a replacement for xfwm under XFCE. You do not need xf86-video-intel/ati/amdgpu's TearFree when you use Compton with the proper settings. (In reply to Carsten Mattner from comment #16) > when only select desktop environments and their wm and/or compositor > hide the problem. GNOME Shell with Mutter and KDE Plasma with KWin do not tear, neither under X11, nor under Wayland. Just switch to GNOME Shell with Mutter or to KDE Plasma with the KWin Vsync option enabled and you no longer will need xf86-video-intel/ati/amdgpu's TearFree. (In reply to Carsten Mattner from comment #16) > xf86-video-intel's TearFree is the only reliable way > right now. xf86-video-ati and xf86-video-amdgpu also have a TearFree option, and both use GLAMOR for acceleration, just like xf86-video-modesetting uses GLAMOR. So if xf86-video-ati and xf86-video-amdgpu support TearFree, then xf86-video-modesetting technically should be able to do the same. Someone just needs to implement it into xf86-video-modesetting. That being said: You only need the TearFree option when you are unable to use a compositor. Since you do already use a compositor though (xfwm / compton) and still see tearing, you obviously are doing something wrong. For starters, just use xf86-video-modesetting on your Intel GPU, then disable compositing in XFCE (to disable it's built-in xfwm compositor) and then start Compton with the following command: compton --paint-on-overlay --backend=glx --glx-swap-method=buffer-age Tearing should be gone now. But you will probably see some input lag. If you want to get rid of tearing and input lag, just switch to GNOME Shell with Mutter or KDE Plasma with the KWin VSync option enabled.
PS: With a rotated screen, there is no tearing with GNOME Shell @ Mutter either, not even under X11. So with GNOME Shell @ Mutter, you do not need TearFree, since there is no tearing in the first place. Presumably, the same should be true for KDE Plasma @ KWin Vsync option enabled. Not sure about multi-monitor though, can't test at the moment.
>(In reply to Carsten Mattner from comment #16) >> neither is compton >> with forced vsync. > >With the proper settings, Compton does not tear, even when you use it as a >replacement for xfwm under XFCE. You do not need xf86-video-intel/ati/amdgpu's >TearFree when you use Compton with the proper settings. I have not found this to be true in the multi-monitor setup with the external monitor rotated. Could you tell us what this configuration that is supposed to completely eliminate all tearing is so I can try it out? Every combination of compton options + X configuration I have tried thus far have failed to fix the issue (including the one you list further down in your e-mail). >Since you do already use a compositor though (xfwm / compton) and still see >tearing, you obviously are doing something wrong. > >For starters, just use xf86-video-modesetting on your Intel GPU, then disable >compositing in XFCE (to disable it's built-in xfwm compositor) and then start >Compton with the following command: > >compton --paint-on-overlay --backend=glx --glx-swap-method=buffer-age > >Tearing should be gone now. But you will probably see some input lag. Running compton with those options does not eliminate tearing on the rotated screen for me with xf86-video-modesetting on xmonad (which has no built-in compositor). This is with an X configuration of: Driver "modesetting" Option "AccelMethod" "glamor" Option "DRI" "3" It is particularly visible when scrolling in Firefox or Chrome (happens with and without smooth scrolling), but also when switching rapidly between workspaces that do and do not have a window, or that have different background images. As a side note, telling people that they are "obviously doing something wrong" isn't particularly helpful :) Jon
Regarding compositors, they are not equal. No tearing under GNOME, but a lot of tearing under https://github.com/compiz-reloaded . What do they do incorrectly?
I tried various things now on the GPD pocket with the rotated 1200x1920 display. With the intel DDX things are smooth, but I got screen corruption. Intel gfx people indicated that I should file a bug for the DRM component, as the DDX seems to trigger a bug in that one, where the modesetting driver apparently is more careful/lucky. With the modesetting driver, I got my tearing. I now observe that there are different kinds of tearing, though. Without any compositor, I got some tearing all over the display (moving around a small terminal window and ovserving the steps in drawing). With the xfce (Xubuntu 17.10, Xfce 4.12) compositor I am not totaly sure how consistent the behaviour is, but it basically looks the same as when running compton --paint-on-overlay --backend=glx --glx-swap-method=buffer-age instead. I there are smooth areas on the screen, but there is extra horrible tearing around the end of first third of the screen from the left (so the actual upper third of the non-rotated screen). In fact, I see some settling of the compositor: at first, there is some normal tearing also in the other regions, but that vanises after some time. With GNOME on X11, I see the same tearing behaviour. The movement of the terminal window is more jerky (so that is the compositor trying to sync things, I presume), but only tearless when not in that screen region where massive tearing is present. The kicker is that I also see the bad first-third tearing in a gnome-shell session with wayland (seems a bit faster to start up than on X11). Movement of the window around the screen generally does feel jerky (so the compositor/whateveritscalledhere does _something_) in comparison, but the nasty tearing is about the same as X11 with modesetting and compositor. With the xf86-video-intel driver, I get a smooth experience that is also devoid of tearing. No jerky movement. Just like the 2D desktop experience of 15 (20?) years ago … but only if I use the TearFree option. Without that, I always have the normal whole-desktop tearing, regardless of a compositor in Xfce (be it xfwm or compton). In gnome-shell, it's the same, somewhat. With TearFree, i got no tearing and only can tell gnome-shell compositing from the Xfce one by the annoyingly jerky movement I get in GNOME. Somehow TearFree in the driver seems to be a magic bullet. But it seems to be the case that my specific nasty modeset tearing experience is due to a peculiar bug of my device / the support of it in the intel DRM component. The _normal_ tearing seems to be healed by compositing, although in a less pleasant manner than proper TearFree at DDX driver level. I do not think it is a good design decision to leave it up to each desktop environment (which could be a simple window manager!) to implement synchronized drawing. It shouldn't even be possible to draw without synchronization! But that's just me … With intel's TearFree, I can watch http://sobukus.de/gpd/displayglitch/kenjo_vidtest_60fps.mp4 without staircases, a nice flicker, be it with -vo xv or -vo gl in mplayer. In the Ubuntu/GNOME wayland session, this looks really bad. Actually I think I see some attempt at syncing kicking in, in that the video stops flickering (dropping every second frame) for a while; that being more prominent on GNOME/X11, though.
Also, (In reply to Jon Gjengset from comment #19) > >(In reply to Carsten Mattner from comment #16) > Could you tell us what this configuration that > is supposed to completely eliminate all tearing is so I can try it out? Just ditch XFCE in favor of native GNOME Shell + Mutter. If you do not like GNOME Shell's UI, just install the Dash to Panel extension https://extensions.gnome.org/extension/1160/dash-to-panel/ and you will probably like GNOME Shell even more than you did like XFCE. With GNOME Shell + Mutter, tearing should be entirely gone without the need for the TearFree option. As I've mentioned, I've tested it with a single rotated screen under GNOME Shell + Mutter @ X11 and Wayland, there is no tearing at all. So you might want to try that out and let us know how it goes for you with multiple monitors (and make sure to test both X11 and Wayland). (In reply to Thomas Orgis from comment #21) > With GNOME on X11, I see the same tearing behaviour. The movement of the > terminal window is more jerky (so that is the compositor trying to sync > things, I presume), but only tearless when not in that screen region where > massive tearing is present. See above. Running Arch Linux here with GNOME 3.28.0 @ Mutter @ GDM @ xf86-video-intel @ SNA @ DRI3 @ TearFree=FALSE or alternatively @ xf86-video-modesetting and there is no tearing, not even with a rotated screen, which is true for X11 and Wayland. Which distro did you test this on and which settings/drivers where you using exactly? (In reply to Thomas Orgis from comment #21) > The kicker is that I also see the bad first-third tearing in a gnome-shell > session with wayland (seems a bit faster to start up than on X11). Movement > of the window around the screen generally does feel jerky (so the > compositor/whateveritscalledhere does _something_) in comparison, but the > nasty tearing is about the same as X11 with modesetting > and compositor. That sounds impossible. Are you sure you were running Wayland? You can check it by running the following command from a terminal: echo $XDG_SESSION_TYPE What does it show? (In reply to Thomas Orgis from comment #21) > With the xf86-video-intel driver, I get a smooth experience that is also > devoid of tearing. No jerky movement. Just like the 2D desktop experience > of 15 (20?) years ago … but only if I use the TearFree option. Without that, > I always have the normal whole-desktop tearing, regardless of a compositor > in Xfce (be it xfwm or compton). In gnome-shell, it's the same, somewhat. Are you saying you are using TearFree=TRUE together with a Compositor simultaneously? I wonder if that is a good idea or if that is how it is intended to be used. I guess when you run a Compositor, you are supposed to set TearFree=FALSE? Can someone comment on it? (In reply to Thomas Orgis from comment #21) > With intel's TearFree, I can watch > http://sobukus.de/gpd/displayglitch/kenjo_vidtest_60fps.mp4 > without staircases, a nice flicker, be it with -vo xv or -vo gl in mplayer. > In the Ubuntu/GNOME wayland session, this looks really bad. Actually I > think I see some attempt at syncing kicking in, in that the video stops > flickering (dropping every second frame) for a while; that being more > prominent on GNOME/X11, though. You probably know this, but just saying: Remember, in a Wayland session, xf86-video-intel / xf86-video-modesetting are not being in use, since those are X11 drivers. (In reply to Thomas Orgis from comment #21) > I do not think it is a good design decision to leave it up to each desktop > environment (which could be a simple window manager!) to implement > synchronized > drawing. It shouldn't even be possible to draw without synchronization! But > that's just me … Agreed. Remember, I was the one to open this feature request (TearFree for xf86-video-modesetting). But at the time I opened it, I was still using XFCE myself. Since then I have switched to KDE Plasma and now GNOME Shell. Both of them do not show tearing at all and are much more smooth than XFCE. Everyone who is using XFCE and is suffering from tearing should try to switch to GNOME Shell + Mutter or alternatively to KDE Plasma + KWin. There really is no reason to use XFCE. GNOME Shell (with extensions) and KDE Plasma can be made to behave and look almost the same as XFCE but do it better than XFCE. This is no rant about XFCE, just stating facts. That being said: Getting a TearFree option for xf86-video-modesetting would still be good, because there might be quite a few applications where you do not use a compositor, such as for example embedded systems or digital signage systems and so on.
(In reply to N. W. from comment #22) > Also, (In reply to Jon Gjengset from comment #19) > > >(In reply to Carsten Mattner from comment #16) > > Could you tell us what this configuration that > > is supposed to completely eliminate all tearing is so I can try it out? > > Just ditch XFCE in favor of native GNOME Shell + Mutter. If you do not like > GNOME Shell's UI, just install the Dash to Panel extension > https://extensions.gnome.org/extension/1160/dash-to-panel/ and you will > probably like GNOME Shell even more than you did like XFCE. PS: You might also want to install Arc Menu: https://github.com/LinxGem33/Arc-Menu
(In reply to N. W. from comment #22) [...] > With GNOME Shell + Mutter, tearing should be entirely gone without the need > for the TearFree option. What video player are you using for playing videos at full screen? At least with totem, vlc and mplayer I still see lots of tearing. The only one that seems to work is mpv (I am not sure if they are maybe forcing the WM to not unredirect it)
(In reply to Pacho Ramos from comment #24) > (In reply to N. W. from comment #22) > [...] > > With GNOME Shell + Mutter, tearing should be entirely gone without the need > > for the TearFree option. > > What video player are you using for playing videos at full screen? At least > with totem, vlc and mplayer I still see lots of tearing. The only one that > seems to work is mpv (I am not sure if they are maybe forcing the WM to not > unredirect it) I've just tested it with KODI, VLC, mpv and Totem at their default settings. With KODI, VLC, and mpv, there is no tearing at all. Even when the video framerate does not match the monitor refresh rate, there is no tearing. However, for some strange reason, there is tearing with Totem. Not sure why it's doing that. But I usually do not use Totem anyway. So just don't use it and you're fine. Just make sure you are using DRI3 (which xf86-video-modesetting has enabled by default whereas it needs to be speficially enabled for xf86-video-intel) and use GNOME Shell @ Mutter or KDE Plasma @ KWin, then you should be fine. Which distro and which version of that distro are you using? Also, which display manager (DM) are you using? With GNOME Shell, you should make sure to use GDM, whereas with KDE Plasma, you should make sure to use SDDM. As mentioned, running Arch Linux with everything up-to-date here (kernel, xorg-server, DDX, Mesa, GNOME, Mutter, GDM etc.).
While the techical comparison of handling of tearing in differing compositors is all well and good, I don't think we will suddenly settle all discussion about what kind of graphical working environment to use. Next we declare that the Atom editor makes all Emacs and Vim users flock to it without hesitation because it's the first and last time the text editor was done right. In fact, I only have Xfce on the GPD Pocket because it was one reasonably lightweight option for a stock system on it before I roll my own confguration that would normally not contain any compositor at all. I have compositors in a mental drawer for ‘eye candy’, not stuff necessary to run a system at all. TearFree I file as a necessity. Also, having one setup of hardware and software where the tearing prevention of your compositor works does not mean that the same configuration works for other hardware. There is a reason compton has so many options that all try to cover vsync, I suppose. There doesn't seem to be one that works for all systems. Back to the technical facts: I believe I do see more than normal tearing on this device. Especially since it is also present under Wayland. I am preparing a bug report to the intel DRM component for this. Another option is that I have defective hardware. I agree that the GNOME compositor seems to suppress the normal tearing … errr no. GNOME on X11 with intel driver and TearFree=false shows the normal tearing happily. In the 60 fps flipping video, that shows nicely with vertical stripes (remember: these are actually horizontal stripes for the display). I can also see it by moving a terminal window around. The tearing is not present when I do not rotate the screen. With the modesetting driver, GNOME on X11 supresses the normal tearing, but suffers from the specific distortion I see on my device for what the kernel DRM bug report is pending (and maybe the hardware is defective after all). I must correct myself regarding Wayland: Apparently, I never ran GNOME on Wayland here. It seems to fall back to X11 without any notice. XDG_SESSION_TYPE is always x11. I can make no statement regarding Wayland performance … apparently I have to configure something to make it work and I spent too much of my weekend on this stuff already. I did not think about the combination of a compositor and TearFree being possibly troublesome. I did not think much about Xfce having a compositor at all before trying to follow your hint with compton. All in all … I'd be happy with any driver giving me stable video without tears. But in the case of this GPD Pocket, I need to first figure out if the underlying issues in hardware or DRM component can be fixed. I'm of no use for the bug being discussed here as long as I got bigger troubles:-/
In my case I am still stuck with Gnome 3.24 on Gentoo, I use gdm and xf86-video-modesetting with kernel 4.14.29. With VLC I only get no tearing if using GL output, not default one
(In reply to Thomas Orgis from comment #26) > In fact, I only have Xfce on the GPD Pocket because it was one reasonably > lightweight option for a stock system on it before I roll my own > confguration that would normally not contain any compositor at all. I have > compositors in a mental drawer for ‘eye candy’, not stuff necessary to run a > system at all. TearFree I file as a necessity. GNOME Shell @ Mutter and KDE Plasma @ KWin are just as leightweight as XFCE is. Besides, while compositors can provide eye candy, both Mutter as well as KWin allow to disable all of that eye candy (animations and so on). And while you can enable wobbly windows on KWin, you can also choose to not do so. (In reply to Thomas Orgis from comment #26) > Also, having one setup of hardware and software where the tearing prevention > of your compositor works does not mean that the same configuration works for > other hardware. There is a reason compton has so many options that all try > to cover vsync, I suppose. There doesn't seem to be one that works for all > systems. I guess the majority of users posting on this thread have Intel graphics hardware, so there is a common ground there. (In reply to Thomas Orgis from comment #26) > I must correct myself regarding Wayland: Apparently, I never ran GNOME on > Wayland here. It seems to fall back to X11 without any notice. > XDG_SESSION_TYPE is always x11. I can make no statement regarding Wayland > performance … apparently I have to configure something to make it work and I > spent too much of my weekend on this stuff already. See, just as I expected. You need to use GDM as the display manager (DM). Only then you will be able to run GNOME Shell @ Mutter @ Wayland. And you need to make sure that "WaylandEnable=false" is commented out in /etc/gdm/custom.conf. And when you log in with GDM, you need to make sure you log in to the "GNOME" session, not to the "GNOME on Xorg" session, see following screenshot: https://diit.cz/sites/default/files/login.png And for KDE Plasma @ KWin, you should use SDDM as the display manager. > All in all … I'd be happy with any driver giving me stable video without > tears. But in the case of this GPD Pocket, I need to first figure out if the > underlying issues in hardware or DRM component can be fixed. I'm of no use > for the bug being discussed here as long as I got bigger troubles:-/ First you should tell us which distribution and which version of distribution you are using. You've been asked this already but did not provide an answer yet. (In reply to Pacho Ramos from comment #27) > In my case I am still stuck with Gnome 3.24 on Gentoo, I use gdm and > xf86-video-modesetting with kernel 4.14.29. With VLC I only get no tearing > if using GL output, not default one Those version numbers sounds recent enough. That being said: Maybe try something more recent? And maybe also try out KDE Plasma @ KWin @ SDDM? You do not even have to install it. To try out a recent version of GNOME, you could just boot the Fedora Rawhide Workstation live ISO (it automatically boots into a Wayland session, but you can control this on login with GDM as mentioned above): https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Workstation/x86_64/iso/ . And to try out a recent version of KDE, you could boot the KDE neon User edition live ISO: https://files.kde.org/neon/images/neon-useredition/current/ . If you try that, it should work out of the box. GNOME Shell @ Mutter does not even have a setting for enabling/disabling VSync I guess. It's just always enabled. However, KDE Plasma @ KWin does have a setting for it, obviously you would need to make sure it's not set to "Never", see following screenshot: https://i.imgur.com/OcKhb0M.png But it should be set to "Automatic" by default anyway, so you shouldn't even have to care about that there either, but just saying, so you know where to check for it.
(In reply to N. W. from comment #28) > GNOME Shell @ Mutter and KDE Plasma @ KWin are just as leightweight as XFCE > is. I do not think that this is the correct place to discuss desktop preferences (hint: I'm not even preferring Xfce for daily work). > I guess the majority of users posting on this thread have Intel graphics > hardware, so there is a common ground there. I mean specifically that not all intel video chips (integrated or not) behave the same in all devices. The DRM driver is called i915 (I actually still got an old netbook with GMA950 graphics …). That implies a long history of differing devices to support. The GPD Pocket I have for sure is different from what people normally have, as Intel chips go. It is an Atom x7-Z8750 SoC connected to a rotated tablet screen. I don't expect it to behave like any other Intel-based laptop. I hoped, though:-/ > You need to use GDM as the display manager (DM). > Only then you will be able to run GNOME Shell @ Mutter @ Wayland. Thanks for pointing that out. It does not help that the LightDM menu offers the Xorg-less sessions, but without them actually giving any hint of not starting Wayland. Off-topic for this bug … > And for KDE Plasma @ KWin, you should use SDDM as the display manager. Damn, where did KDM go? ;-) But again: off-topic here. > First you should tell us which distribution and which version of > distribution you are using. You've been asked this already but did not > provide an answer yet. Sorry. Maybe I was a bit lazy just noting Xubuntu 17.10 and Xfce 4.12. I installed the nexus511 Xubuntu 17.04 image for the GPD Pocket and updated that to 17.10. Then I built and installed the kernel from https://github.com/jwrdegoede/linux-sunxi.git commit ae718bc, basing the config on the one by nexus511 (https://github.com/nexus511/gpd-ubuntu-packages/). I briefly installed the current git version of xf86-video-intel. Apart from the GPD-specific tweaks, it's a standard Xubuntu 17.10 with current updates. This is all test-driving the GPD before installing my usual system on it. I'm no expert in things (X)Ubuntu. Even the one Xubuntu machine I regularily run has Fluxbox as ‘desktop’. That works nicely on Thinkpad X230 with HD 4000 graphics, of course with TearFree and the intel driver. My attention is now directed towards bug #105834. My more basic trouble needs to be sorted first before trying to fix normal tearing with xf86-video-modesetting.
(In reply to Thomas Orgis from comment #29) > (In reply to N. W. from comment #28) > > GNOME Shell @ Mutter and KDE Plasma @ KWin are just as leightweight as XFCE > > is. > > I do not think that this is the correct place to discuss desktop preferences > (hint: I'm not even preferring Xfce for daily work). This thread is about users complaining that xf86-video-modesetting has no TearFree option. Obviously, X11 without a compositor or without a TearFree DDX option will tear. xf86-video-modesetting does not yet have a TearFree option. So I guess it's fine to tell people here how to get rid of tearing in the meantime, since that is ultimately what this thread is for. If that involves changing the desktop environment, then so be it. (In reply to Thomas Orgis from comment #29) > Sorry. Maybe I was a bit lazy just noting Xubuntu 17.10 and Xfce 4.12. I > installed the nexus511 Xubuntu 17.04 image for the GPD Pocket and updated > that to 17.10. Then I built and installed the kernel from > https://github.com/jwrdegoede/linux-sunxi.git commit ae718bc, basing the > config on the one by nexus511 > (https://github.com/nexus511/gpd-ubuntu-packages/). I briefly installed the > current git version of xf86-video-intel. Apart from the GPD-specific tweaks, > it's a standard Xubuntu 17.10 with current updates. > > This is all test-driving the GPD before installing my usual system on it. > I'm no expert in things (X)Ubuntu. Even the one Xubuntu machine I regularily > run has Fluxbox as ‘desktop’. That works nicely on Thinkpad X230 with HD > 4000 graphics, of course with TearFree and the intel driver. > > My attention is now directed towards bug #105834. My more basic trouble > needs to be sorted first before trying to fix normal tearing with > xf86-video-modesetting. Choosing Xubuntu was probably the biggest mistake that you could have made in terms of achieving a tear free experience, which is what many people here are trying to explain to you guys complaining about tearing on Xubuntu (XFCE). So, what is your "usual system"? Why not try that one? Also, what about trying Wayland? As you said, you never actually ran Wayland before? Just live boot into the Fedora Rawhide Workstation live ISO https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Workstation/x86_64/iso/ and see how it goes and let us know here (not recommending Fedora per se, but that ISO makes it easy to boot into a GNOME Wayland session without having to install anything)?
(In reply to N. W. from comment #30) > So, what is your "usual system"? Why not try that one? The usual system is Source Mage (the other source-based distro of about the same age as Gentoo), which is a bit like Linux From Scratch, but with a package manager. I was just using what the community came up with regarding adaptions to the GPD Pocket, beginning with Hans de Goede's kernel and numerous tweaks like the display rotation from boot. At some point, I want to take the configuration and patches I know are needed, and then ‘port’ Source Mage. It started with Ubuntu respins, but some folks are running Arch on the GPD, too. I'm don't know much about Fedora, but I have a suspicion that Hans himself is running that (him being part of the Fedora project and all that;-). But support for the GPD may be too bleeding-edge for a standard ISO to work just like that. That's why we're building kernels from Hans' sunxi tree. My main concern now is to find out if my hardware is defective or if I am only triggering a driver bug with the display corruption and special tearing. The distro is rather irrelevant there. Even a (normally) tear-free modesetting driver would not help me at this point. I'll come back here once the intel DDX is killed off for good for my next intel-based video chip …
For completeness: I booted the indicated Fedora Rawhide ISO with Wayland. I did not observe tearing there. I could not do the full testing including the flicker video as the live system cannot play h264 and the system gave me neither working wifi nor support for my USB C hub with Ethernet, so I was unable to get the missing software installed. Seems like not all GPD Pocket support patches reached Fedora yet. But yeah, GNOME on Wayland seems to get the tearing prevention right, from what I can tell by messing around a bit on the desktop. It also keep 40% of a CPU busy for moving a cursor in front of a terminal window. I'd need a proper benchmark, but Xfce or a plain window manager definitely need less. But I don't intend to fill this bug report with this discussion. The fact is that tearing does not appear to be an issue with that software setup here.
(In reply to Thomas Orgis from comment #32) > It also keep 40% of > a CPU busy for moving a cursor in front of a terminal window. I'd need a > proper benchmark, but Xfce or a plain window manager definitely need less. > But I don't intend to fill this bug report with this discussion. Possibly related to: https://bugzilla.gnome.org/show_bug.cgi?id=745032
> As I've mentioned, I've tested it with a single rotated screen under GNOME Shell + Mutter @ X11 and Wayland, there is no tearing at all. Good for you, however with Gnome Shell X11, Mutter, modesetting I observe opposite behaviour on Dell 5855, 7140, 9250, DEXP 7W, 10XW and Lenovo Miix2 8, all running Ubuntu Gnome 16.04-18.04 (I use vanilla Gnome session, not Ubuntu one). Sure, with Wayland there is no tearing but Wayland session can not be used on mentioned tablets (because OnboardOSK is unfinished, and current Caribou is unusable with 1280x720 screens, or even with 1920x1080 screens with 150% fractional scaling - because bottom line of keyboard is not fit on the screen in landscape orientation; so there simply no choice besides X11 session with Onboard, therefore I have to pick between modesetting DDX and intel DDX; and, yes, there is rendering artefacts with intel DDX, sometimes in terminal, sometimes in Gnome's Save dialog, etc.)
Setting to importance "highest - critical" since almost all major distros have switched from xf86-video-intel to xf86-video-modesetting by default and a lot of people still seem to see tearing even with compositors such as Mutter and KWin, especially on rotated screens. Obviously this is not ideal at all considering there are a lot of devices out there which make use of rotated screens. Since xf86-video-ati and xf86-video-amdgpu already have a TearFree option implemented which also works on rotated outputs and since both make use of GLAMOR for acceleration (xf86-video-modesetting also uses GLAMOR for acceleration), it would be nice if the Xorg devs could comment on why xf86-video-modesetting is still lacking a TearFree option.
FWIW, as I pointed out in comment 3, an X11 compositor cannot prevent tearing with RandR rotation, because the latter is applied after the compositor draws its output.
(In reply to Michel Dänzer from comment #36) > FWIW, as I pointed out in comment 3, an X11 compositor cannot prevent > tearing with RandR rotation, because the latter is applied after the > compositor draws its output. Makes it even stranger that TearFree is not implemented in xf86-video-modesetting.
Moving from component "Driver/modesetting" to "Server/General". Also raising from importance "highest - critical" to "highest - blocker". Maybe that way it will get the attention from the Xorg developers (they did not yet seem to have commented on this one here) and maybe that way something could still be done before xorg-server 1.20 is being released. Because otherwise Ubuntu users will see tearing for a looong time.
Also added a few email aliases to this thread that have recently been active on working on xf86-video-modesetting: https://cgit.freedesktop.org/xorg/xserver/log/?qt=grep&q=modesetting
Doubt I'll be working on this, so a friendly advice would be to give it a stab yourself. It's a good learning experience plus there are three drivers to draw inspiration from.
Just adding my support for this. I've recently moved to a multi-monitor setup with rotated displays, and the tearing has been a real pain to deal with. I ended up switching to xf86-video-intel for the TearFree option, but the intel drivers come with their own set of issues and instability, as others have pointed out. I really do hope that someone picks this up, as a huge portion of the userbase is currently forced to pick between stability (modesetting driver), and a tear-free desktop experience (intel).
I'd consider chipping in for a bounty to motivate a dev to work on this.
This issue has been resolved
Now this is working as expected
If it's fixed then what version exactly?
Maybe he is just some kind of bot? Reverting status from "RESOLVED/CLOSED" to "NEW" since this does not seem to be fixed yet (no commit has been linked).
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/244.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.