X11 clipboard problems on Slackware/KDE/Klipper/x86_64

Issue #2 open
arcfide
created an issue

When using Acme on Slackware Linux -Current x86_64 version with KDE, Acme fails to behave properly respecting the clipboard.

Cut/Snarf/Paste commands accessed or run via middle-click command button work fine and as expected. However, the cut mouse chord does not behave correctly when Klipper is enabled. Instead, the clipboard items are pasted and no text is ever added to the clipboard from the mouse chord action.

If Klipper is disabled, Then cutting and pasting using any method works, but none of the contents are ever added to the X selection or clipboard buffers, making it impossible to paste cut or snarfed text outside of the Acme application.

I am unsure whether these are related or separate issues.

Comments (16)

  1. arcfide reporter

    Is there any progress on this? How can I get this fixed? It really is a bother. I'd be willing to examine some of the code and do some debugging if I could be pointed in the right direction.

  2. Russ Cox repo owner

    Just to clarify the situation, your report is that:

    Without Klipper running:

    1. Cut or Snarf in acme followed by paste in an ordinary X app DOES NOT work.
    2. cut/snarf via chord in acme followed by paste in an ordinary X app DOES NOT work.
    3. cut in an ordinary X app followed by Paste in acme DOES NOT work.
    4. cut in an ordinary X app followed by paste via chord in acme DOES NOT work.

    With Klipper running:

    1. Cut or Snarf in acme followed by paste in an ordinary X app works.
    2. cut/snarf via chord in acme followed by paste in an ordinary X app DOES NOT work.
    3. cut in an ordinary X app followed by Paste in acme works.
    4. cut in an ordinary X app followed by paste via chord in acme DOES NOT work.

    Is that correct? It's pretty hard to imagine what could be causing that, because the same code runs to interact with the X11 clipboard regardless of whether a chord or a button-2 command is being used.

  3. arcfide reporter

    Not exactly. Here's the behavior:

    With Klipper running OR not running:

    1. Cut or Snarf in Acme followed by a paste in an ordinary X app does NOT work. 2. Chording cut/snarf in Acme followed by a paste does NOT work.

    With Klipper Running:

    1. Selection and then a Paste via chord or command works. 2. Snarf and Cut commands pasting back into Acme works. 3. Snarf and Cut commands or Chording followed by paste into an X app does NOT work. 4. Chording Cut/Paste back into Acme does NOT Work. 5. Selecting and pasting from an X app into Acme with Chording or command works.

    Without Klipper runing, I can paste from an X app into Acme, but I cannot cut, snarf any data from ACme into an X app. I can using Cut and Snarf via chord or command and then paste back into acme, but not outside of Acme.

  4. Russ Cox repo owner

    I still do not understand the problem. Your previous description is not quite the crisp characterization I was hoping for. Let me try and simplify.

    At the bottom level, there are three operations that acme does:

    1. copy and take ownership of clipboard
    2. paste when acme owns clipboard
    3. paste when something else owns clipboard

    In X11 there is no clipboard buffer, only a clipboard owner. To get the clipboard contents, an app asks the owner to send the data in a particular format.

    It sounds like:

    • without Klipper, 1 is broken, 2 might work, and 3 is working.
    • with Klipper, 1 is broken, 2 is working, and 3 is working.

    Is that correct?

    The reason you'd get different behavior with Klipper is that when Klipper notices acme take ownership of the clipboard, it copies the data from acme and then takes ownership itself. This means that when Klipper is running, acme ends up in case 3 where it used to be in case 2. Unfortunately, Klipper took control of the clipboard but didn't get the right data because 1 is broken.

    Does this match what you're seeing? We really need a crisp statement of the problem before there is any hope of figuring out what's wrong.

    The relevant code is in src/cmd/devdraw/x11-itrans.c; the main routines are called _xgetsnarf and _xputsnarf, but the one that is probably not working is called _xselect. That routine gets called when another app requests the clipboard data from acme. You'll see there is already a commented out (if(0)'ed out) fprint there. That's worth uncommenting. The target and property and selection are all atoms, which are numbers representing strings. The command xlsatoms will dump the X11 server's current mapping from numbers to strings. It's possible that _xselect is being asked for the data in a format it does not understand, but except when that format is "TIMESTAMP" it is supposed to print an error before sending back nothing.

    You can test changes by running mk install in the devdraw directory and then restarting acme (no need to recompile acme). You should see output written to standard error from devdraw (fprint(2, "foo %d\n", 2)) on the running acme's standard error.

  5. arcfide reporter

    Your assessment appears to be correct. I have not investigated further, but it does appear that the problem is Acme not taking control of the Clipboard. This results in no active changes when copying with Klipper (Acme still pastes from Klipper, because Klipper owns the clipboard), and results in the inability of other programs to utilize the Acme clipboard buffer, because ownership isn't properly assigned. Otherwise, it appears that Acme can paste correctly from the clipboard owners, whether this is the Acme or the other program, Klipper or otherwise. The only thing that doesn't quite make sense here is that when Klipper is disabled, Acme has no trouble using its own clipboard, it's just other programs that have trouble. I am guessing that Acme is requesting the clipboard information in a way that it understands, so it provides the data appropriately, whereas the other programs do not. With Klipper enabled, any attempt to work with the clipboard is "captured" by Klipper, so Acme never sees itself as owner and it instead pastes from the data that Klipper has, which is never updated, because Acme and the other programs aren't communicating regarding the Acme clipboard contents.

    I think this is basically what you are saying above, with the one additional manifestation of this that Acme loses control of the clipboard when Klipper is enabled, which is what causes the strange behavior, whereas, without Klipper, the other programs don't steal control, and hence, Acme can pastes in its own world fine, though other programs fail to get Acme clipboard data.

    I don't know when I will have time to enable the debugging information, but if you have any suggested directions, or if you know how to fix this, that would be wonderful. It's quite a pain. :-)

    Thank you for your help on this issue so far, and may I say, great work on Plan9ports!

  6. Russ Cox repo owner

    When you say "I have not investigated further" what does that mean?

    Did you uncomment the print in _xselect and see what acme prints for selection requests?

  7. arcfide reporter

    I uncommented the printf and this is the result I got from copying some text and then trying to paste it from outside of the application.

    xselect target=294 requestor=67108919 property=298 selection=292 xselect target=294 requestor=71303223 property=298 selection=1 xselect target=294 requestor=71303223 property=298 selection=292 xselect target=294 requestor=71303223 property=298 selection=292 xselect target=294 requestor=71303223 property=298 selection=1

  8. arcfide reporter

    Reformatted:

    xselect target=294 requestor=67108919 property=298 selection=292
    xselect target=294 requestor=71303223 property=298 selection=1
    xselect target=294 requestor=71303223 property=298 selection=292
    xselect target=294 requestor=71303223 property=298 selection=292
    xselect target=294 requestor=71303223 property=298 selection=1
    
  9. Russ Cox repo owner

    You need to translate each of those small numbers into atom strings, by looking at the output of xlsatoms. In the text you showed, the target is 294, the property is 298, and the selection is either 1 or 292. It would be nice to know what atoms those are (1 == XA_PRIMARY but the others are dynamically allocated).

    xlsatoms | awk '$1==1||$1==292||$1==294||$1==298'
    

    You will need to substitute the actual numbers into the awk command after running the test again. Each time you start an X server you can end up with different atom mappings.

    Russ

  10. arcfide reporter

    Here's what I get when I write some text, copy it in Acme, paste it inside of Acme, and then try to paste it outside of Acme with the middle-click and Paste menu item of KWrite.

    arcfide@onyx:/opt/plan9/src/cmd/devdraw$ acme
    xselect target=294 requestor=52428855 property=298 selection=1
    xselect target=294 requestor=52428855 property=298 selection=292
    arcfide@onyx:/opt/plan9/src/cmd/devdraw$ xlsatoms | awk '$1==1||$1==52428855||$1==298||$1==292'
    1       PRIMARY
    292     CLIPBOARD
    298     _QT_SELECTION
    arcfide@onyx:/opt/plan9/src/cmd/devdraw$
    
  11. Log in to comment