Compile error on DEV version using DRI3 option

[DocMAX]

Allready added -DTVNC_DRI3=1 to my PKGBUILD...

pkgname=turbovnc-git
pkgver=3.1.1.r35.gddad0148
pkgrel=1
pkgdesc="High-speed remote desktop software (development version)"
arch=('x86_64')
url="https://www.turbovnc.org/"
license=('GPL')
depends=('java-runtime' 'libx11' 'libjpeg-turbo' 'libxt' 'libxmu' 'libxi')
makedepends=('git' 'cmake' 'make' 'gcc')
provides=('turbovnc')
conflicts=('turbovnc')
source=('git+https://github.com/TurboVNC/turbovnc.git#branch=dev')
sha256sums=('SKIP')

pkgver() {
  cd "$srcdir/turbovnc"
  git describe --long --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'
}

build() {
  cd "$srcdir/turbovnc"
  mkdir -p build
  cd build
  PATH=/usr/bin:$PATH
  cmake .. \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DTJPEG_INCLUDE_DIR=/usr/include \
    -DTJPEG_LIBRARY=/usr/lib/libturbojpeg.so \
    -DTVNC_DRI3=1
  make
}

package() {
  cd "$srcdir/turbovnc/build"
  make DESTDIR="$pkgdir" install
}

[dcommander]

Note that this was a compiler warning, so it was only fatal because your build apparently makes compiler warnings fatal. Also, our build system disables compiler warnings for a lot of the X.org code, including damageext.c, so I'm not sure why your build encountered the warning in the first place. Anyhow, it should be fixed now.

I saw your comment on the TigerVNC thread, but I do not work on weekends as a general rule. Issues with this project are usually addressed during normal business hours, and I am in EDT (GMT-4 at the moment.)

[DocMAX]

Confirmed, works! Thank you very much. Now i'm very exited to test it.

[dcommander]

I look forward to your feedback. I need to eventually implement the get_formats() DRI3 method, which AMD's Vulkan implementation sometimes seems to use. (In particular, the lack of a get_formats() implementation causes Xvnc to crash when launching VMWare, which by default uses Vulkan for 3D acceleration.) I also believe that I can improve upon the Pixmap-to-buffer-object synchronization mechanism, which currently occurs on a timer.

[DocMAX]

So i did some tests now. vkcube and vulkaninfo are working. But i see flickering on my desktop. (Terminal background color flickers with desktop background) Games seem to work (using wine with dxvk) :-).

[DocMAX]

[DocMAX]

Is it better to use the TuboVNC Viewer? Right now i use the TigerVNC client. But there is no simple TurboVNC vncviewer.exe around :-(

[dcommander]

So what was the initial problem with WINE? Note that it is better to post a follow-up comment explaining the source of the initial failure and how it was resolved rather than editing your comment. Others may learn from your experiences.

The TurboVNC Viewer is written in Java and includes an embedded JRE. Install one of our pre-built Windows packages, then use c:\program files\turbovnc\vncviewer.bat if you want to use the viewer from the command line. It will work just as well as a .exe file. It's worth trying the TurboVNC Viewer, but I doubt that it will eliminate the flickering. I suspect that the flickering is a bug in the DRI3 implementation. I will try to reproduce the issue. You're using Xfce? What is your server platform?

[DocMAX]

I didn't fix anything. It must have been some kind of input error i did. Not sure what i did and probably not worth mentioning. But here is a video of the screen flicker in case i didn't explain well... https://jumpshare.com/s/hhwDdXI67ouSf777niir Also the Steam GUI is filckering like crazy.

It's Arch Linux with XFCE4 and a custom skin (Chigago95)

[dcommander]

OK, will try to repro.

[DocMAX]

Holy grail! This feature is a real game changer! I can stop using SteamLink or Sunshine Video streaming. It's already looking that good and all games run as if I were running on plain X-server. They also use the current resolution of the window, which is very nice. Great work! Can't believe you initially didn't want to implement this. Looking forward to fixing the flickering issues and optimizing the code. As I said, please check the Steam GUI. It's flickering the most here. The games, by the way, do NOT flicker. Thank you! :-)

[dcommander]

I am barely able to eek out a living by developing and maintaining this project and VirtualGL and libjpeg-turbo, so it is difficult to justify the labor necessary to implement, integrate, fix, document, and maintain a major new feature if no one is paying for that labor. As far as I know, all deployments of TurboVNC in corporations and academia, organizations that might be in a position to pay for the implementation/integration of a feature like this, use nVidia GPUs, so the feature is useless to them.

As implemented by Kasm, the feature has some drawbacks, as evidenced by the flickering and the inability to run VMWare and other issues. I am honestly not sure if I can fix the flickering, because I suspect that it is due to the fact that Pixmaps and GBM buffer objects currently have to be synchronized on a timer within Xvnc. That's because Xvnc knows when a Pixmap has changed, but it doesn't necessarily know when a buffer object has changed (because that occurs within the 3D application process.) VirtualGL, in fact, exists partly to solve that synchronization dilemma for OpenGL applications: it monitors the GLX calls from such applications so it knows when a frame has been rendered and is ready for transport. I need to spend a day digging into the issue before I know whether it is solvable, and I haven't been able to find that time yet.

I integrated the DRI3 feature into TurboVNC in the hope of gaining familiarity with it so I could formally estimate the labor necessary to fix it, but even the company that implemented the feature isn't interested in that right now. (The vast majority of their customers also use nVidia GPUs, so they can't make a business case for it any more than I can.)

I hope this sheds some light on why I can't just spend time on everything that may appeal to me on a technical level. As an independent developer, I am generally more free to set the project agenda, but I still rely on outside contributions to support that agenda. I have to wear multiple hats, including project manager and product manager and marketing. From a business point of view, the DRI3 feature is primarily marketing. If the feature can be implemented correctly, then it will probably bring more users to TurboVNC, which will improve the project's overall health and exposure. That is how I am able to justify working on it at all, but there's a limit to how much free work I can do to improve the project's health and exposure. (Frankly, AMD should be paying for it, since it benefits primarily their GPUs.)

[DocMAX]

OK, thanks for the work so far.