Qt does not draw pixels where they should be on X11

Support Graphics & Display
, ,
1

Hello everyone.

I am working on the qt app where I need to draw lines on the screen. The problem is that lines I am drawing with the standard qt methods are completelly wrong – they are tearing without any movement. I also have my own algorithm to draw lines so I am sure that coordinates of each pixel are correct, but they are not correctly represented on screen.

I’ve run my code on other OS’s and it works perfect. It also works perfect if I switch from X11 to Wayland, but I don’t want to use the last one because it works awful with everything else. I’ve also tried to switch from qt5 to qt6 and it didn’t help at all.

So I assumed that the problem is not in qt but in my system and created a file /etc/X11/xorg.conf.d/20-amdgpu.conf with the contents:
Section “Device”
Identifier “AMD Graphics”
Driver “amdgpu”
Option “TearFree” “true”
Option “TripleBuffer” “true”
Option “AccelMethod” “uxa”
EndSection

It didn’t help either. How can I fix this bug?

2
1 Like
3

I beleve it is not a qt problem, because changing qt versions doesn’t make any difference. But changing OS and Wayland does.

4

If your code doesn’t work correctly on X11 then it is either a problem with your code or a problem with Qt + X11. It is not a Manjaro problem.

5

My code works with X11 not on Manjaro OS, I tested It as well.

6

How do you determine “determine without movement”. Typically, tearing is happening during movement. I don’t understand your problem.

This "AccelMethod" "uxa" is for Intel GPUs and can’t be applied on AMD GPUs.

Same with TripleBuffer

1 Like
7

Unfortunately, I am not allowed to add screenshot here, but I will try to describe:

I am drawing a 45 degree line from the top left to the bottom right. So if the starting point is (x, y), I expect next pixel to appear on the (x + 1, y + 1) and so on. But on screen I have several correct pixels, than at this thing: (x + 1, y), (x + 1, y + 1), (x + 1, y + 2). Then the line is right again for a short period. And It all goes over and over.

8

Could you add your system info?

9

inxi -v8azy

System:
  Kernel: 6.6.19-1-MANJARO arch: x86_64 bits: 64 compiler: gcc v: 13.2.1
    clocksource: hpet avail: acpi_pm
  Desktop: KDE Plasma v: 5.27.11 tk: Qt v: 5.15.12 info: frameworks
    v: 5.115.0 wm: kwin_x11 vt: 2 dm: SDDM Distro: Manjaro base: Arch Linux

Graphics:
  Device-1: AMD Lucienne vendor: QUANTA driver: amdgpu v: kernel arch: GCN-5
    code: Vega process: GF 14nm built: 2017-20 pcie: gen: 3 speed: 8 GT/s
    lanes: 16 link-max: gen: 4 speed: 16 GT/s ports: active: eDP-1
    empty: HDMI-A-1 bus-ID: 03:00.0 chip-ID: 1002:164c class-ID: 0300
    temp: 36.0 C
  Device-2: IMC Networks HD Camera driver: uvcvideo type: USB rev: 2.0
    speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 1-4:3 chip-ID: 13d3:5480
    class-ID: fe01 serial: <filter>
  Display: x11 server: X.Org v: 21.1.11 with: Xwayland v: 23.2.4
    compositor: kwin_x11 driver: X: loaded: amdgpu dri: radeonsi gpu: amdgpu
    display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22")
    s-diag: 582mm (22.93") monitors: <missing: xrandr>
  Monitor-1: eDP-1 model: BOE Display 0x0936 built: 2020 res: 1920x1080
    dpi: 142 gamma: 1.2 chroma: red: x: 0.639 y: 0.329 green: x: 0.298 y: 0.600
    blue: x: 0.149 y: 0.059 white: x: 0.314 y: 0.329
    size: 344x194mm (13.54x7.64") diag: 395mm (15.5") ratio: 16:9
    modes: 1920x1080, 1680x1050, 1280x1024, 1440x900, 1280x800, 1280x720,
    1024x768, 800x600, 640x480
  API: EGL v: 1.5 hw: drv: amd radeonsi platforms: device: 0 drv: radeonsi
    device: 1 drv: swrast surfaceless: drv: radeonsi x11: drv: radeonsi
    inactive: gbm,wayland
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 24.0.2-manjaro1.1
    glx-v: 1.4 direct-render: yes renderer: AMD Radeon Graphics (radeonsi renoir
    LLVM 16.0.6 DRM 3.54 6.6.19-1-MANJARO) device-ID: 1002:164c memory: 500 MiB
    unified: no
  API: Vulkan v: 1.3.279 layers: N/A device: 0 type: integrated-gpu name: AMD
    Radeon Graphics (RADV RENOIR) driver: mesa radv v: 24.0.2-manjaro1.1
    device-ID: 1002:164c surfaces: xcb,xlib

mhwd -li -l

> Installed PCI configs:
--------------------------------------------------------------------------------
                  NAME               VERSION          FREEDRIVER           TYPE
--------------------------------------------------------------------------------
           video-linux            2018.05.04                true            PCI


Warning: No installed USB configs!
> 0000:03:00.0 (0300:1002:164c) Display controller ATI Technologies Inc:
--------------------------------------------------------------------------------
                  NAME               VERSION          FREEDRIVER           TYPE
--------------------------------------------------------------------------------
           video-linux            2018.05.04                true            PCI
     video-modesetting            2020.01.13                true            PCI
            video-vesa            2017.03.12                true            PCI

I am not sure that it is everything that might be useful.

10

This is not conclusive evidence!

Depending on the graphics system used, qt has to implement the “internal” paint and draw commands differently. Qt has a whole range of settings for this. Some of these affect the thickness of a line, or how it is rendered…

As far as I know, there is no routine that sets a single point directly without going through the entire graphics system. Transformations are applied, antialiasing…

You can get a lot of unexpected effects there. Of course also those that are only visible on a specific backend.
So if you want to call it a bug… I would rather say that it is a misunderstanding between you and qt.
:footprints:

It’s better to use the routines from the Qt library. Not only is it easier, but they really work. :wink:

11

I’ve already said that standard library functions don’t work on this operation system in particular. My task as a student is to implement functions to draw lines myself, and I mentioned it only to let you know that I now for a fact that I am providing standard qt methods with right coordinates.

Why does this misunderstanding happens only on Manjaro with X11 then?