STR #2419: Cut / Copy don't work on X11 - Fast Light Toolkit (FLTK)

STR #2419

Application:	FLTK Library
Status:	1 - Closed w/Resolution
Priority:	2 - Low, e.g. a documentation error or undocumented side-effect
Scope:	2 - Specific to an operating system
Subsystem:	X11
Summary:	Cut / Copy don't work on X11
Version:	1.3-current
Created By:	moe
Assigned To:	AlbrechtS
Fix Version:	1.3.0 (SVN: v7837)
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

#1	AlbrechtS 05:18 Nov 11, 2010

str-2419_r7817.patch
1k

Trouble Report Comments:

#1	moe 15:16 Sep 23, 2010

Using SVN r7704, I get this error message in the terminal whenever I try to copy, cut ot mouse-select: X_ChangeProperty: BadValue (integer parameter out of range for operation) 0x40 No text was copied to the clipboard or mouse selection. Pasting works fine, but of course only with content from other apps. It is visible in all FLTK apps.

#2	AlbrechtS 16:07 Sep 27, 2010

I can't reproduce this. Copy/cut'n'paste/drag'n'drop all work for me on Ubuntu 9.04 with default (gnome) desktop and also if I use a Windows (Cygwin) X server to access the linux box. Tested with test/input (.cxx) successfully. Is it possible that you mixed old 1.1 and new 1.3 FLTK versions? If not, please describe: (a) your configuration WRT operating system, window manager etc. (b) what *exactly* does not work? Copy and paste by marking with dragging to the "selection" or with CTRL/C to the clipboard, or ...

#3	greg.ercolano 17:20 Sep 27, 2010

I can't replicate with Ubuntu 8.04 + Gnome default on 32bit. I /can/ replicate with Ubuntu 8.04 + Gnome default on 64bit. For example, using test/editor, highlighting default text, and hitting Edit -> Copy. In both cases, fresh checkout of latest svn, and rebuild. Seems to be x64 specific.

#4	greg.ercolano 19:54 Sep 27, 2010

I think cause is this XChangeProperty line Fl_x.cxx: ---- if (e.target == TARGETS) { Atom a = fl_XaUtf8String; //XA_STRING; XChangeProperty(fl_display, e.requestor, e.property, XA_ATOM, sizeof(Atom)*8, 0, (unsigned char*)&a, 1); ---- It's really hard to trace this, because even if you put fprintf(stderr) around this line, it doesn't encase the message from XLIB, probably because the operation that causes it gets delayed in the X event queue. If I comment out that line, the error message goes away. The complaint from XLIB regarding "0x40" seems to be that sizeof(Atom)*8 which on a 64bit machine is 0x40. I'm not really sure what this operation does, or why there's a *8 in there, and don't know what the fix is. It's obviously the UTF8 stuff, and I think we've actually been here before, not sure..

#5	yuri 02:06 Sep 28, 2010

I have the same message on copy or cut operation. X_ChangeProperty: BadValue (integer parameter out of range for operation) 0x40 but Cut and Paste works fine.

#6	moe 04:15 Sep 28, 2010

This is Kubuntu 10.04 on AMD64. No mixed FLTK versions, it also happens if I statically link r7704. It seems to be app-independent, but just in case: The two apps I experienced this in are fluid (again, SVN r7704) and teapot ( http://www.syntax-k.de/projekte/teapot ).

#7	moe 04:27 Sep 28, 2010

I just tested it. It is indeed an AMD64-specific bug. In a 32-bit build copy/paste and mouse selection work flawlessly.

#8	AlbrechtS 02:56 Sep 29, 2010

Some info I found so far: XChangeProperty is used here to tell the "requestor" which type of selection we have (in this case fl_XaUtf8String). The format argument of this call must be size of the property value (Atom a) in bytes, and thus it is (has always been) sizeof(Atom)*8. So far, so good... The problem seems to be that the format argument must be one of 8, 16, or 32, but is 64 (0x40). One solution *might* be to replace the two lines in question with: int a = fl_XaUtf8String; //XA_STRING; XChangeProperty(fl_display, e.requestor, e.property, XA_ATOM, sizeof(a)*8, 0, (unsigned char*)&a, 1); but this could give another warning, so that we would maybe need a cast: int a = (int)fl_XaUtf8String; //XA_STRING; To verify this, would you please add the following printf statement (before changing anything) just before the XChangeProperty call and report what it prints on your 64-bit system? Atom a = fl_XaUtf8String; //XA_STRING; printf ("sizeof(Atom)=%d, sizeof(unsigned long)=%d, a=%ld\n", sizeof(Atom), sizeof(unsigned long), a); XChangeProperty(fl_display, e.requestor, e.property, XA_ATOM, sizeof(Atom)*8, 0, (unsigned char*)&a, 1); $ test/input sizeof(Atom)=4, sizeof(unsigned long)=4, a=234 sizeof(Atom)=4, sizeof(unsigned long)=4, a=234 This is my code and what it reports. --- With the code changed like this: unsigned int a = fl_XaUtf8String; //XA_STRING; printf ("sizeof(a)=%d, sizeof(unsigned long)=%d, a=%u\n", sizeof(a), sizeof(unsigned long), a); XChangeProperty(fl_display, e.requestor, e.property, XA_ATOM, sizeof(a)*8, 0, (unsigned char*)&a, 1); ... it reports: $ test/input sizeof(a)=4, sizeof(unsigned long)=4, a=234 sizeof(a)=4, sizeof(unsigned long)=4, a=234 Note: I used test/input, entered some characters in one of the input fields, marked some text, and pressed ctrl/c. What does it report with the changed code, and does it work?

#9	AlbrechtS 03:00 Sep 29, 2010

Two corrections: The 2nd sentence should read: "The format argument of this call must be _the_ size of the property value (Atom a) in *bits*, and thus it is (has always been) sizeof(Atom)*8." I used "unsigned int" in the modified code instead of "int" (as I wrote before).

#10	greg.ercolano 12:03 Sep 29, 2010

> size of the property value (Atom a) in *bits*, Oh... OK, that explains the '8'. > To verify this, would you please add the following printf > statement (before changing anything) just before the > XChangeProperty call and report what it prints on your > 64-bit system? Sure; here's the printf() results without changes: ---- root@delta:/usr/local/src/fltk-1.3.x-svn/test# ./editor sizeof(Atom)=8, sizeof(unsigned long)=8, a=275 X_ChangeProperty: BadValue (integer parameter out of range for operation) 0x40 ----

#11	greg.ercolano 12:07 Sep 29, 2010

Here's the results with your recommended change.. and there's *no error* now: ---- root@delta:/usr/local/src/fltk-1.3.x-svn/test# ./editor sizeof(a)=4, sizeof(unsigned long)=8, a=275 ---- Your fix might be good.

#12	AlbrechtS 04:19 Sep 30, 2010

Thanks for testing. Yes, it might be good, but I'm looking for more insight in the discussion in fltk.development: http://www.fltk.org/newsgroups.php?gfltk.development+QSTR%232419 Maybe there's a better way. At least it's a workaroung for those who need it now.

#13	AlbrechtS 05:17 Nov 11, 2010

Greg, may I ask you (or anybody else) to test the attached patch (str-2419_r7817.patch) on a 64-bit big-endian and on a 64-bit little-endian system? Both system types are interesting. Maybe I can setup a 64-bit little-endian system, but I definitely don't have a big-endian one. TIA for all who test and report their results.

#14	greg.ercolano 10:27 Nov 11, 2010

Unfortunately, cannot test on 64bit big endian due to STR #2439..! http://fltk.org/str.php?L2439 Also, my little endian 64bit linux box has decided to take a crap; won't boot the kernel due to some problem with the hard drive :/

#15	AlbrechtS 00:52 Nov 12, 2010

Greg, didn't you solve the compiler problem (STR 2439)? Otherwise you could try it with an older svn version, by simply using svn up -r nnnn. I'll try to set up a 64-bit little endian vm for testing at the weekend.

#16	greg.ercolano 14:49 Nov 12, 2010

Right, I'll try again this weekend.. still wrapping up the work week.

#17	greg.ercolano 10:45 Nov 13, 2010

Patch works OK on fedora14/64bit intel small endian. Also works on SGI.. sorta. (I think I'm encountering a problem unrelated to this STR) If I select text and use mouse to Edit->Copy / Edit->Paste it works fine. But the ^C/^V/^A shortcuts do not work; they all type c/v/a characters, as if the CTRL key wasn't involved. Details: I no longer have an SGI monitor, and my newer LCD monitors can't handle the SGI's signal, so I can't test directly on the SGI console; I have to rsh from a linux box and run the app as a remote-X connection. So problem /might/ be related to that. I notice the same behavior with the test/input program, so Matt, I don't think this has anything to do with your recent dev on editor. However: if I run the SGI 'nedit' program (GUI editor), its ^C/^V/^A shortcuts work fine. Also: The FLTK test/menubar program's CTRL-A shortcut triggers properly. So I'm thinking something is wrong with how FLTK's input widgets (editors/input) are looking for CTRL keys that the menubar app is getting correct. It's weird though, because if I run the 'menubar' application, hitting CTRL-A triggers the CTRL+A shortcut, so it seems to only be affecting the built-in ^C/^V shortcuts..? I get the same bad behavior from the 'input' test program; ^C, ^V, and ^A all generate c/v/a chars respectively. This is probably fodder for a different STR. Certainly I haven't seen any X warnings.

#18	greg.ercolano 11:03 Nov 13, 2010

I've submitted a separate STR (#2444) for the above unrelated issue. http://www.fltk.org/str.php?L2444

#19	AlbrechtS 23:17 Nov 14, 2010

I've set up an Ubuntu 10.10/64-bit (little endian) system, tested, and it works as expected. Since Greg opened another STR for the unrelated problem, I committed the patch (r7837).

#20	AlbrechtS 23:18 Nov 14, 2010

Fixed in Subversion repository.