#6 closed defect (worksforme)
Emacs Issues: xpra locks up, screen stops re-drawing
Reported by: | FredSRichardson | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | major | Milestone: | 0.0.7.x |
Component: | client | Version: | 0.0.7.26 |
Keywords: | Cc: |
Description (last modified by )
I'm working with a recent version off the SVN repo (the date on the sources is 2011-08-02 19:36).
I've found two problems: one is occasional lockups and the other has to do with screen redrawing.
I'm not sure what causes the lockups, sometimes they are cured by minimizing and maximizing or by killing the xpra attach session and re-attaching.
The screen re-drawing is a consistent problem when scrolling through a lot of text. It looks as though emacs isn't keeping up with the redrawing somehow (a lot of "artifacts" are left in the buffer). This wasn't a problem in older versions of xpra, so I wonder if there's a setting that might help.
Here's output from the console:
$ xpra attach ssh:fdata1:14 'setxkbmap -query' failed with exit code 255 Missing window or missing property or wrong property type PULSE_SERVER (latin1) Missing window or missing property or wrong property type PULSE_COOKIE (latin1) Missing window or missing property or wrong property type PULSE_ID (latin1) Attached (press Control-C to detach) /usr/local/lib/python/xpra/xposix/xclipboard.py:227: GtkWarning: gdk_x11_atom_to_xatom_for_display: assertion `ATOM_TO_INDEX (atom) < virtual_atom_array->len' failed gtk.Invisible.do_selection_request_event(self, event)
Attachments (1)
Change History (10)
Changed 8 years ago by
Attachment: | fdata1-14.log added |
---|
comment:1 Changed 8 years ago by
Description: | modified (diff) |
---|---|
Status: | new → accepted |
comment:2 Changed 8 years ago by
comment:3 Changed 8 years ago by
Summary: | Emacs Issues → Emacs Issues: xpra locks up, screen stops re-drawing |
---|
Did any of this help?
How does it differ from #14? (some useful info there too)
comment:4 Changed 8 years ago by
Aren't these disabled by default? That is, I can't imagine I would want any refresh delay, so the default 0.0 should be correct. Similarly it looks like jpeg-quality and max-bandwidth are not limited by default. Am I missing something?
I have tried -z 0 to turn off all compression and no-pulseaudio. I also tried no-clipboard, but I actually need the clipboard...
comment:5 Changed 8 years ago by
Yes, these are disabled by default, the refresh delay should help in your case: it will do a full screen refresh after the delay, which may help solve your problems with garbled screen updates by refreshing the whole screen. It would be useful to know if it helps.
comment:7 Changed 8 years ago by
current trunk will honour the --auto-refresh-delay=DELAY
even when not using jpeg encoding, see --encoding
option.
Does this help (as a workaround - not a real fix)?
comment:8 Changed 8 years ago by
Resolution: | → worksforme |
---|---|
Status: | accepted → closed |
No updates, closing.
comment:9 Changed 8 years ago by
Milestone: | → 0.0.7.x |
---|---|
Version: | → 0.0.7.26 |
I'm not sure about the lockups, and there isn't anything suspicious in the logs.
Also, I use vi not emacs, so I'm not sure exactly how to reproduce. Feel free to post emacs steps for dummies!
As for the refresh issue: although it was not meant to be used for that, this option may help in your case (at least it will cleanup the mess):
IIRC, you will have to enable jpeg compression for this option to have an effect, either:
or
Let me know if that helps.