Clear specific X buffer directly, without going through xsel or xclipHow can I turn off “middle mouse...

Plausibility of Ice Eaters in the Arctic

Are any jet engines used in combat aircraft water cooled?

How does The Fools Guild make its money?

Is it possible to script what applications should open certain file extensions?

Does two puncture wounds mean venomous snake?

Keeping a Weakness Secret

Replace data between quotes in a file

Sierpinski turtle triangle

Dropdowns & Chevrons for Right to Left languages

How can I tell if a flight itinerary is fake?

Do other countries guarantee freedoms that the United States does not have?

Can I call myself an assistant professor without a PhD

Should I self-publish my novella on Amazon or try my luck getting publishers?

Improving software when the author can see no need for improvement

In Pokémon Go, why does one of my Pikachu have an option to evolve, but another one doesn't?

Does a code snippet compile? Or does it gets compiled?

Did WWII Japanese soldiers engage in cannibalism of their enemies?

How would I as a DM create a smart phone-like spell/device my players could use?

SQL Minimum Row count

How quickly could a country build a tall concrete wall around a city?

In a topological space if there exists a loop that cannot be contracted to a point does there exist a simple loop that cannot be contracted also?

How can glass marbles naturally occur in a desert?

Is refreshing multiple times a test case for web applications?

Pretty heat maps



Clear specific X buffer directly, without going through xsel or xclip


How can I turn off “middle mouse button paste” functionality in all programs?Linux using whole swap, becoming unresponsive while there is plenty of free RAMHow do command line clipboard tools like “xclip” and “xsel” persist the clipboard - in a X windows environment that doesn't?Export Display is not working on Ubuntu Gnome (gmd3)StructureNotifyMask interferes with other windows on linux Mint






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







2















I am trying to completely disable middle-click for pasting from a buffer, using Radivarig's solution.




Place this in ~/.xbindkeysrc



"echo -n | xsel -n -i; pkill xbindkeys; xdotool click 2; xbindkeys"
b:2 + Release



This solution, however, depends on xsel (or, equivalently, xclip) completing its job quickly.



Recently I've noticed a delay of several seconds for xsel and xclip when attempting to clear the primary buffer.



Is there a less "polite" way than whatever xsel or xclip are doing to force X to empty a specific buffer?



The Linux distribution in question is Manjaro ... this could be a Manjaro or Arch-specific bug, but end-user-oriented information about how to interact with the X11 server without xsel or xclip or another similar tool seems to be somewhat lacking.



~  > xclip -selection primary -verbose -in </dev/null
Connected to X server.
Using selection: XA_PRIMARY
Using UTF8_STRING.
Waiting for selection requests, Control-C to quit
Waiting for selection request number 1
Waiting for selection request number 2
Time: 13s

~ > xclip -selection primary -verbose -in </dev/null
...
Time: 11s

~ > xclip -selection primary -verbose -in </dev/null
...
Time: 23s


I attached gdb to one of the hung xclips and it appears to be stuck waiting for a response from the X server.



(gdb) where
#0 0x00007f905e1f1b78 in poll () from /usr/lib/libc.so.6
#1 0x00007f905dc68630 in ?? () from /usr/lib/libxcb.so.1
#2 0x00007f905dc6a2db in xcb_wait_for_event () from /usr/lib/libxcb.so.1
#3 0x00007f905e306009 in _XReadEvents () from /usr/lib/libX11.so.6
#4 0x00007f905e2f4ee1 in XNextEvent () from /usr/lib/libX11.so.6
#5 0x0000563eb8eaea70 in ?? ()
#6 0x00007f905e125223 in __libc_start_main () from /usr/lib/libc.so.6
#7 0x0000563eb8eaf53e in ?? ()


I attempted to write a stripped down program using the X API directly, based on part of the xsel source code, in particular: https://github.com/kfish/xsel/blob/master/xsel.c#L1003-L1018 .



In order to clear the buffer, xsel appears to be relying on this property of XSetSelectionOwner:




If the new owner (whether a client or None ) is not the same as the
current owner of the selection and the current owner is not None , the
current owner is sent a SelectionClear event. If the client that is
the owner of a selection is later terminated (that is, its connection
is closed) or if the owner window it has specified in the request is
later destroyed, the owner of the selection automatically reverts to
None , but the last-change time is not affected. The selection atom is
uninterpreted by the X server. XGetSelectionOwner() returns the owner
window, which is reported in SelectionRequest and SelectionClear
events. Selections are global to the X server.




Here's my attempt to strip down xsel to just the functionality I need.



I'm assuming that the owner of the XA_PRIMARY buffer usually isn't None. I am setting it to None inside the body of my C program and then hoping it worked.



// clear.c
#include <stdio.h>
#include <X11/Xlib.h>
#include <X11/Xatom.h>
#include <assert.h>

// always debug
#undef NDEBUG

static Display * display = NULL;

static char * display_name = NULL;

static void clear_selection(void)
{
printf("%dn", 300);
display = XOpenDisplay(display_name);
assert(display != NULL);
printf("%dn", 200);
XSetSelectionOwner(display, XA_PRIMARY, None, CurrentTime);
printf("%dn, 500);
XSync(display, False);
return;
}

int main(void)
{
printf("%dn", 100);
clear_selection();
printf("%dn", 200);
return 0;
}


This program runs and prints



100
300
400
500
200


as expected.



However, it failed to clear the primary buffer.



xclip -selection -primary out shows the same thing before and after.










share|improve this question

































    2















    I am trying to completely disable middle-click for pasting from a buffer, using Radivarig's solution.




    Place this in ~/.xbindkeysrc



    "echo -n | xsel -n -i; pkill xbindkeys; xdotool click 2; xbindkeys"
    b:2 + Release



    This solution, however, depends on xsel (or, equivalently, xclip) completing its job quickly.



    Recently I've noticed a delay of several seconds for xsel and xclip when attempting to clear the primary buffer.



    Is there a less "polite" way than whatever xsel or xclip are doing to force X to empty a specific buffer?



    The Linux distribution in question is Manjaro ... this could be a Manjaro or Arch-specific bug, but end-user-oriented information about how to interact with the X11 server without xsel or xclip or another similar tool seems to be somewhat lacking.



    ~  > xclip -selection primary -verbose -in </dev/null
    Connected to X server.
    Using selection: XA_PRIMARY
    Using UTF8_STRING.
    Waiting for selection requests, Control-C to quit
    Waiting for selection request number 1
    Waiting for selection request number 2
    Time: 13s

    ~ > xclip -selection primary -verbose -in </dev/null
    ...
    Time: 11s

    ~ > xclip -selection primary -verbose -in </dev/null
    ...
    Time: 23s


    I attached gdb to one of the hung xclips and it appears to be stuck waiting for a response from the X server.



    (gdb) where
    #0 0x00007f905e1f1b78 in poll () from /usr/lib/libc.so.6
    #1 0x00007f905dc68630 in ?? () from /usr/lib/libxcb.so.1
    #2 0x00007f905dc6a2db in xcb_wait_for_event () from /usr/lib/libxcb.so.1
    #3 0x00007f905e306009 in _XReadEvents () from /usr/lib/libX11.so.6
    #4 0x00007f905e2f4ee1 in XNextEvent () from /usr/lib/libX11.so.6
    #5 0x0000563eb8eaea70 in ?? ()
    #6 0x00007f905e125223 in __libc_start_main () from /usr/lib/libc.so.6
    #7 0x0000563eb8eaf53e in ?? ()


    I attempted to write a stripped down program using the X API directly, based on part of the xsel source code, in particular: https://github.com/kfish/xsel/blob/master/xsel.c#L1003-L1018 .



    In order to clear the buffer, xsel appears to be relying on this property of XSetSelectionOwner:




    If the new owner (whether a client or None ) is not the same as the
    current owner of the selection and the current owner is not None , the
    current owner is sent a SelectionClear event. If the client that is
    the owner of a selection is later terminated (that is, its connection
    is closed) or if the owner window it has specified in the request is
    later destroyed, the owner of the selection automatically reverts to
    None , but the last-change time is not affected. The selection atom is
    uninterpreted by the X server. XGetSelectionOwner() returns the owner
    window, which is reported in SelectionRequest and SelectionClear
    events. Selections are global to the X server.




    Here's my attempt to strip down xsel to just the functionality I need.



    I'm assuming that the owner of the XA_PRIMARY buffer usually isn't None. I am setting it to None inside the body of my C program and then hoping it worked.



    // clear.c
    #include <stdio.h>
    #include <X11/Xlib.h>
    #include <X11/Xatom.h>
    #include <assert.h>

    // always debug
    #undef NDEBUG

    static Display * display = NULL;

    static char * display_name = NULL;

    static void clear_selection(void)
    {
    printf("%dn", 300);
    display = XOpenDisplay(display_name);
    assert(display != NULL);
    printf("%dn", 200);
    XSetSelectionOwner(display, XA_PRIMARY, None, CurrentTime);
    printf("%dn, 500);
    XSync(display, False);
    return;
    }

    int main(void)
    {
    printf("%dn", 100);
    clear_selection();
    printf("%dn", 200);
    return 0;
    }


    This program runs and prints



    100
    300
    400
    500
    200


    as expected.



    However, it failed to clear the primary buffer.



    xclip -selection -primary out shows the same thing before and after.










    share|improve this question





























      2












      2








      2








      I am trying to completely disable middle-click for pasting from a buffer, using Radivarig's solution.




      Place this in ~/.xbindkeysrc



      "echo -n | xsel -n -i; pkill xbindkeys; xdotool click 2; xbindkeys"
      b:2 + Release



      This solution, however, depends on xsel (or, equivalently, xclip) completing its job quickly.



      Recently I've noticed a delay of several seconds for xsel and xclip when attempting to clear the primary buffer.



      Is there a less "polite" way than whatever xsel or xclip are doing to force X to empty a specific buffer?



      The Linux distribution in question is Manjaro ... this could be a Manjaro or Arch-specific bug, but end-user-oriented information about how to interact with the X11 server without xsel or xclip or another similar tool seems to be somewhat lacking.



      ~  > xclip -selection primary -verbose -in </dev/null
      Connected to X server.
      Using selection: XA_PRIMARY
      Using UTF8_STRING.
      Waiting for selection requests, Control-C to quit
      Waiting for selection request number 1
      Waiting for selection request number 2
      Time: 13s

      ~ > xclip -selection primary -verbose -in </dev/null
      ...
      Time: 11s

      ~ > xclip -selection primary -verbose -in </dev/null
      ...
      Time: 23s


      I attached gdb to one of the hung xclips and it appears to be stuck waiting for a response from the X server.



      (gdb) where
      #0 0x00007f905e1f1b78 in poll () from /usr/lib/libc.so.6
      #1 0x00007f905dc68630 in ?? () from /usr/lib/libxcb.so.1
      #2 0x00007f905dc6a2db in xcb_wait_for_event () from /usr/lib/libxcb.so.1
      #3 0x00007f905e306009 in _XReadEvents () from /usr/lib/libX11.so.6
      #4 0x00007f905e2f4ee1 in XNextEvent () from /usr/lib/libX11.so.6
      #5 0x0000563eb8eaea70 in ?? ()
      #6 0x00007f905e125223 in __libc_start_main () from /usr/lib/libc.so.6
      #7 0x0000563eb8eaf53e in ?? ()


      I attempted to write a stripped down program using the X API directly, based on part of the xsel source code, in particular: https://github.com/kfish/xsel/blob/master/xsel.c#L1003-L1018 .



      In order to clear the buffer, xsel appears to be relying on this property of XSetSelectionOwner:




      If the new owner (whether a client or None ) is not the same as the
      current owner of the selection and the current owner is not None , the
      current owner is sent a SelectionClear event. If the client that is
      the owner of a selection is later terminated (that is, its connection
      is closed) or if the owner window it has specified in the request is
      later destroyed, the owner of the selection automatically reverts to
      None , but the last-change time is not affected. The selection atom is
      uninterpreted by the X server. XGetSelectionOwner() returns the owner
      window, which is reported in SelectionRequest and SelectionClear
      events. Selections are global to the X server.




      Here's my attempt to strip down xsel to just the functionality I need.



      I'm assuming that the owner of the XA_PRIMARY buffer usually isn't None. I am setting it to None inside the body of my C program and then hoping it worked.



      // clear.c
      #include <stdio.h>
      #include <X11/Xlib.h>
      #include <X11/Xatom.h>
      #include <assert.h>

      // always debug
      #undef NDEBUG

      static Display * display = NULL;

      static char * display_name = NULL;

      static void clear_selection(void)
      {
      printf("%dn", 300);
      display = XOpenDisplay(display_name);
      assert(display != NULL);
      printf("%dn", 200);
      XSetSelectionOwner(display, XA_PRIMARY, None, CurrentTime);
      printf("%dn, 500);
      XSync(display, False);
      return;
      }

      int main(void)
      {
      printf("%dn", 100);
      clear_selection();
      printf("%dn", 200);
      return 0;
      }


      This program runs and prints



      100
      300
      400
      500
      200


      as expected.



      However, it failed to clear the primary buffer.



      xclip -selection -primary out shows the same thing before and after.










      share|improve this question
















      I am trying to completely disable middle-click for pasting from a buffer, using Radivarig's solution.




      Place this in ~/.xbindkeysrc



      "echo -n | xsel -n -i; pkill xbindkeys; xdotool click 2; xbindkeys"
      b:2 + Release



      This solution, however, depends on xsel (or, equivalently, xclip) completing its job quickly.



      Recently I've noticed a delay of several seconds for xsel and xclip when attempting to clear the primary buffer.



      Is there a less "polite" way than whatever xsel or xclip are doing to force X to empty a specific buffer?



      The Linux distribution in question is Manjaro ... this could be a Manjaro or Arch-specific bug, but end-user-oriented information about how to interact with the X11 server without xsel or xclip or another similar tool seems to be somewhat lacking.



      ~  > xclip -selection primary -verbose -in </dev/null
      Connected to X server.
      Using selection: XA_PRIMARY
      Using UTF8_STRING.
      Waiting for selection requests, Control-C to quit
      Waiting for selection request number 1
      Waiting for selection request number 2
      Time: 13s

      ~ > xclip -selection primary -verbose -in </dev/null
      ...
      Time: 11s

      ~ > xclip -selection primary -verbose -in </dev/null
      ...
      Time: 23s


      I attached gdb to one of the hung xclips and it appears to be stuck waiting for a response from the X server.



      (gdb) where
      #0 0x00007f905e1f1b78 in poll () from /usr/lib/libc.so.6
      #1 0x00007f905dc68630 in ?? () from /usr/lib/libxcb.so.1
      #2 0x00007f905dc6a2db in xcb_wait_for_event () from /usr/lib/libxcb.so.1
      #3 0x00007f905e306009 in _XReadEvents () from /usr/lib/libX11.so.6
      #4 0x00007f905e2f4ee1 in XNextEvent () from /usr/lib/libX11.so.6
      #5 0x0000563eb8eaea70 in ?? ()
      #6 0x00007f905e125223 in __libc_start_main () from /usr/lib/libc.so.6
      #7 0x0000563eb8eaf53e in ?? ()


      I attempted to write a stripped down program using the X API directly, based on part of the xsel source code, in particular: https://github.com/kfish/xsel/blob/master/xsel.c#L1003-L1018 .



      In order to clear the buffer, xsel appears to be relying on this property of XSetSelectionOwner:




      If the new owner (whether a client or None ) is not the same as the
      current owner of the selection and the current owner is not None , the
      current owner is sent a SelectionClear event. If the client that is
      the owner of a selection is later terminated (that is, its connection
      is closed) or if the owner window it has specified in the request is
      later destroyed, the owner of the selection automatically reverts to
      None , but the last-change time is not affected. The selection atom is
      uninterpreted by the X server. XGetSelectionOwner() returns the owner
      window, which is reported in SelectionRequest and SelectionClear
      events. Selections are global to the X server.




      Here's my attempt to strip down xsel to just the functionality I need.



      I'm assuming that the owner of the XA_PRIMARY buffer usually isn't None. I am setting it to None inside the body of my C program and then hoping it worked.



      // clear.c
      #include <stdio.h>
      #include <X11/Xlib.h>
      #include <X11/Xatom.h>
      #include <assert.h>

      // always debug
      #undef NDEBUG

      static Display * display = NULL;

      static char * display_name = NULL;

      static void clear_selection(void)
      {
      printf("%dn", 300);
      display = XOpenDisplay(display_name);
      assert(display != NULL);
      printf("%dn", 200);
      XSetSelectionOwner(display, XA_PRIMARY, None, CurrentTime);
      printf("%dn, 500);
      XSync(display, False);
      return;
      }

      int main(void)
      {
      printf("%dn", 100);
      clear_selection();
      printf("%dn", 200);
      return 0;
      }


      This program runs and prints



      100
      300
      400
      500
      200


      as expected.



      However, it failed to clear the primary buffer.



      xclip -selection -primary out shows the same thing before and after.







      x11 clipboard






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 1 hour ago









      muru

      43.5k5 gold badges108 silver badges181 bronze badges




      43.5k5 gold badges108 silver badges181 bronze badges










      asked Oct 16 '18 at 21:46









      Gregory NisbetGregory Nisbet

      1,52111 silver badges26 bronze badges




      1,52111 silver badges26 bronze badges

























          1 Answer
          1






          active

          oldest

          votes


















          2















            XSetSelectionOwner(display, XA_PRIMARY, None, CurrentTime);



          This will not work. As the first line in the DESCRIPTION of XSetSelectionOwner(3) says:




          The XSetSelectionOwner function changes the owner and last-change time
          for the specified selection and has no effect if the specified time is
          earlier than the current last-change time of the specified selection
          or
          is later than the current X server time.




          You'll have to pass it a real timestamp, which you could obtain from an XEvent received from the server. This is what I did in my own implementation of xsel:



          Time getctime(void){
          XSelectInput(dpy, w, PropertyChangeMask);
          XStoreName(dpy, w, "xsel");
          for(;;){
          XEvent e;
          XNextEvent(dpy, &e);
          if(e.type == PropertyNotify && e.xproperty.window == w)
          return e.xproperty.time;
          }
          }


          I set a property on a window, wait for the PropertyNotify event and then get the timestamp from the XPropertyEvent structure. The window can be an InputOnly one. This is also described in the xlib programming manual, or some X11 manpage.



          Unfortunately, that will also mean that your little program won't be quick enough either, as it has to wait for that event ;-)



          I don't think that the answers to the linked question are satisfactory. You better explore using some LD_PRELOAD hack, or modifying the programs that are causing you trouble.






          share|improve this answer






























            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "106"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f475906%2fclear-specific-x-buffer-directly-without-going-through-xsel-or-xclip%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            2















              XSetSelectionOwner(display, XA_PRIMARY, None, CurrentTime);



            This will not work. As the first line in the DESCRIPTION of XSetSelectionOwner(3) says:




            The XSetSelectionOwner function changes the owner and last-change time
            for the specified selection and has no effect if the specified time is
            earlier than the current last-change time of the specified selection
            or
            is later than the current X server time.




            You'll have to pass it a real timestamp, which you could obtain from an XEvent received from the server. This is what I did in my own implementation of xsel:



            Time getctime(void){
            XSelectInput(dpy, w, PropertyChangeMask);
            XStoreName(dpy, w, "xsel");
            for(;;){
            XEvent e;
            XNextEvent(dpy, &e);
            if(e.type == PropertyNotify && e.xproperty.window == w)
            return e.xproperty.time;
            }
            }


            I set a property on a window, wait for the PropertyNotify event and then get the timestamp from the XPropertyEvent structure. The window can be an InputOnly one. This is also described in the xlib programming manual, or some X11 manpage.



            Unfortunately, that will also mean that your little program won't be quick enough either, as it has to wait for that event ;-)



            I don't think that the answers to the linked question are satisfactory. You better explore using some LD_PRELOAD hack, or modifying the programs that are causing you trouble.






            share|improve this answer
































              2















                XSetSelectionOwner(display, XA_PRIMARY, None, CurrentTime);



              This will not work. As the first line in the DESCRIPTION of XSetSelectionOwner(3) says:




              The XSetSelectionOwner function changes the owner and last-change time
              for the specified selection and has no effect if the specified time is
              earlier than the current last-change time of the specified selection
              or
              is later than the current X server time.




              You'll have to pass it a real timestamp, which you could obtain from an XEvent received from the server. This is what I did in my own implementation of xsel:



              Time getctime(void){
              XSelectInput(dpy, w, PropertyChangeMask);
              XStoreName(dpy, w, "xsel");
              for(;;){
              XEvent e;
              XNextEvent(dpy, &e);
              if(e.type == PropertyNotify && e.xproperty.window == w)
              return e.xproperty.time;
              }
              }


              I set a property on a window, wait for the PropertyNotify event and then get the timestamp from the XPropertyEvent structure. The window can be an InputOnly one. This is also described in the xlib programming manual, or some X11 manpage.



              Unfortunately, that will also mean that your little program won't be quick enough either, as it has to wait for that event ;-)



              I don't think that the answers to the linked question are satisfactory. You better explore using some LD_PRELOAD hack, or modifying the programs that are causing you trouble.






              share|improve this answer






























                2












                2








                2








                  XSetSelectionOwner(display, XA_PRIMARY, None, CurrentTime);



                This will not work. As the first line in the DESCRIPTION of XSetSelectionOwner(3) says:




                The XSetSelectionOwner function changes the owner and last-change time
                for the specified selection and has no effect if the specified time is
                earlier than the current last-change time of the specified selection
                or
                is later than the current X server time.




                You'll have to pass it a real timestamp, which you could obtain from an XEvent received from the server. This is what I did in my own implementation of xsel:



                Time getctime(void){
                XSelectInput(dpy, w, PropertyChangeMask);
                XStoreName(dpy, w, "xsel");
                for(;;){
                XEvent e;
                XNextEvent(dpy, &e);
                if(e.type == PropertyNotify && e.xproperty.window == w)
                return e.xproperty.time;
                }
                }


                I set a property on a window, wait for the PropertyNotify event and then get the timestamp from the XPropertyEvent structure. The window can be an InputOnly one. This is also described in the xlib programming manual, or some X11 manpage.



                Unfortunately, that will also mean that your little program won't be quick enough either, as it has to wait for that event ;-)



                I don't think that the answers to the linked question are satisfactory. You better explore using some LD_PRELOAD hack, or modifying the programs that are causing you trouble.






                share|improve this answer
















                  XSetSelectionOwner(display, XA_PRIMARY, None, CurrentTime);



                This will not work. As the first line in the DESCRIPTION of XSetSelectionOwner(3) says:




                The XSetSelectionOwner function changes the owner and last-change time
                for the specified selection and has no effect if the specified time is
                earlier than the current last-change time of the specified selection
                or
                is later than the current X server time.




                You'll have to pass it a real timestamp, which you could obtain from an XEvent received from the server. This is what I did in my own implementation of xsel:



                Time getctime(void){
                XSelectInput(dpy, w, PropertyChangeMask);
                XStoreName(dpy, w, "xsel");
                for(;;){
                XEvent e;
                XNextEvent(dpy, &e);
                if(e.type == PropertyNotify && e.xproperty.window == w)
                return e.xproperty.time;
                }
                }


                I set a property on a window, wait for the PropertyNotify event and then get the timestamp from the XPropertyEvent structure. The window can be an InputOnly one. This is also described in the xlib programming manual, or some X11 manpage.



                Unfortunately, that will also mean that your little program won't be quick enough either, as it has to wait for that event ;-)



                I don't think that the answers to the linked question are satisfactory. You better explore using some LD_PRELOAD hack, or modifying the programs that are causing you trouble.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Oct 16 '18 at 22:54

























                answered Oct 16 '18 at 22:32









                mosvymosvy

                15.7k2 gold badges18 silver badges51 bronze badges




                15.7k2 gold badges18 silver badges51 bronze badges

































                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Unix & Linux Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f475906%2fclear-specific-x-buffer-directly-without-going-through-xsel-or-xclip%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Taj Mahal Inhaltsverzeichnis Aufbau | Geschichte | 350-Jahr-Feier | Heutige Bedeutung | Siehe auch |...

                    Baia Sprie Cuprins Etimologie | Istorie | Demografie | Politică și administrație | Arii naturale...

                    Nicolae Petrescu-Găină Cuprins Biografie | Opera | In memoriam | Varia | Controverse, incertitudini...