search

Xpra-org / xpra

Persistent remote applications for X11; screen sharing for X11, MacOS and MSWindows.
https://xpra.org/
GNU General Public License v2.0
1.9k stars 164 forks source link

xpra desktop has psychotic update habits in a local terminal #4319

Closed karlkleinpaste closed 4 weeks ago

karlkleinpaste commented 1 month ago

Large local xpra desktop, managed by fvwm, within which I maintain a bunch of terminals for this and several other machines, where I do things like sysadmin tasks together.

Within that desktop, I have xpra-driven terminals for the other machines, but a local terminal started out of fvwm menus. So the terminal, on its own, has no special display properties that it wouldn't have if it were displayed on the native desktop.

Activity on that terminal shows deeply aberrant redisplay of old content as I perform routine tasks, in this case, a dnf update download. Attached .mp4 shows what happens.

Entirely fedora39 36448. Entirely local, no remote access.

  1. XPRA_LOG_PREFIX=[minor:28] xpra start-desktop :28 --attach=no --resize-display=5112x1362 --start-child=vfvwm
  2. XPRA_LOG_PREFIX=[minor:28] xpra attach :28 --border=turquoise,2
  3. Use fvwm menus to open a terminal. This terminal is not driven by xpra, other than living within the xpra-driven fvwm desktop.

Do stuff in the terminal. It will mis-"remember" old content. As the dnf command works, content that was in the terminal from an early point keeps coming back up. When the command ends, the final state is again garbage, but when I hit a few Enter keys, it suddenly reverts to the state that it should and does actually have.

Apologies for the fuzzy video; github wouldn't accept the 12Mbyte original, so I downsized with with ffmpeg -vf "scale=iw/2:ih/2".

https://github.com/user-attachments/assets/740e9237-38b0-4459-b57d-a8dfe6ef4634

karlkleinpaste commented 1 month ago

What the heck. The embedded video can't be played? I opened the bug report specifically to have a rendezvous point to show that video. As I see it, the video is entirely greyed out, no controls are active to my mouse.

karlkleinpaste commented 1 month ago

Use ftp to reach ftp.xiphos.org, where you will find the original .mkv in directory /pub/video.

totaam commented 1 month ago

I haven't looked at the video yet but from your description, this sounds an awful lot like #4201 If so, then turning opengl off, or using --encodings=no-scroll should workaround it. Normally, I would be thrilled to hear of a new symptom as this would help me narrow down on the bug, in this case however, I have already spent weeks (on and off) chasing this particular bug - and by the look of things, I have made things worse..

karlkleinpaste commented 1 month ago

Just to be clear... I know opengl=no is a client side option. Is encodings=no-scroll for server or client side? Perhaps both? The man page does not mention much detail about encodings, simply cautioning against using it at all. When working through other bugs in the past, you have recommended things like encodings=-h264 to leave other options present, so I'm wondering about the effect of setting a single value like no-scroll.

totaam commented 1 month ago

Is encodings=no-scroll for server or client side? Perhaps both?

Both. It should be listed as a server-driven option, meaning that the client cannot enable encodings that the server has not enabled. In this case, using on the client should be enough. As for -h264 vs no-scroll, the no-XXX syntax was added recently. I assume that you're running git master since you're hitting the scroll bug.

karlkleinpaste commented 1 month ago

I still have my 36439 build available, and installed that; the problem does not occur with 36439. So whatever has happened has been after 36439 and up to 36448 -- I hope that can help you determine where the cause is.

karlkleinpaste commented 1 month ago

Re-installed 36448, can confirm --opengl=no makes things OK again.

Also, I can't quantify or document this exactly, but I have an impression that, only in 36448, moving windows within the desktop, i.e. any of the several terminal windows there, is ... jerky. The windows don't move smoothly, they jump several pixels at a time as I grab a title bar and they are moved from one spot on the desktop to another. No idea if this is related.

totaam commented 1 month ago

@karlkleinpaste is 0cac56aa4dc8454e737216ccfb38c1f206769b49 enough to make things mostly work again? Not perfectly until #4201 is properly fixed, but usable?

Looking at the recent opengl commits, eddc282c348b3c4bb5bae00588eb3d32b6dd66b6 is the only other commit that is suspicious.

karlkleinpaste commented 1 month ago

I just rebuilt 36472 and restarted that desktop. Unfortunately, the moment I open the first local terminal and start writing commands, it's leaving behind garbage visual traces. The white blocks at the end of "noRecall" and beneath "Last login" should not be there, being apparent incomplete remnants of the block cursor that was briefly there.

screenshot1

As I do other random activity in the terminal, garbage spots like this clear themselves up, but they come back irregularly.

This is without opengl=no, of course.

totaam commented 1 month ago

Assuming that the revision scripts work exactly the same way on your systems as they do on mine:

Obtained by running:

git checkout eddc282c348b3c4bb5bae00588eb3d32b6dd66b6
rm xpra/src_info.py
./fs/bin/add_build_info.py | grep REVISION

Looking at these 9 commits, the only drawing related entries are:

totaam commented 1 month ago

OK, so I managed to reproduce some very strange behaviour by using desktop scaling, and this allowed me to bisect https://github.com/Xpra-org/xpra/issues/4324#issuecomment-2285853637 - leading back to #2467, which is nowhere near the commits above... but, the same fix also worked for #4201 So, I am hoping that what you were seeing was a result of desktop scaling (fixed) or also related to FBO initialization somehow. @karlkleinpaste can you try again please?

karlkleinpaste commented 1 month ago

I'll get to it later today.

karlkleinpaste commented 1 month ago

I think we're there. I'm not using --opengl=no and I'm not seeing mis-remembered garbage. Thanx.

totaam commented 4 weeks ago

Unfortunately, I am still seeing occasional issues where the opengl renderer gets wedged. :( It's as if the windows' opengl contexts are somehow interfering with each other.

Reproduced by just running glxgears from an xterm with the client using --opengl=force.

totaam commented 4 weeks ago

Well, that turned out to be a nightmare and I still don't know why the fix was needed: 775d435b83097b0d97d55b3173ab5d9503ee5971 glClear does something that is required when we use scaling with glBlitFramebuffer. I found that out by just trying things at random out of sheer desperation.

(the geometry fixes aren't actually important since we always use double-buffered visuals and those always paint the whole window - so although the arguments were the wrong ones, the result was not)