Re: 64-bit Clipboard troubles
On 21/06/13 13:33, Jon TURNEY wrote: On 10/06/2013 22:39, David Stacey wrote: >On 10/06/13 14:30, Jon TURNEY wrote: >>On 09/06/2013 19:59, David Stacey wrote: >>> >I am trying to package keepassx for 64-bit Cygwin, and have noticed a >>> >difference between the way the clipboard functions under 32-bit and 64-bit >>> >Cygwin/X. Essentially, keepassx is an encrypted password database that >>> >copies your username and password to the clipboard. Then, you can paste >>> >these into a web site (say) to log in. >>> > >>> >When I run keepassx (both 32-bit and 64-bit builds) using the 32-bit >>> >version of XWin, keepassx copies the username and password to the >>> >clipboard, and these can be pasted into a native Windows web browser (e.g. >>> >Firefox). However, when I run keepassx (again, both 32-bit and 64-bit >>> >builds) using the 64-bit version of XWin, the procedure breaks: I instruct >>> >keepassx to copy to the clipboard, but when I paste in the web browser, no >>> >text is pasted. >>Sorry, integration between the native and X clipboards is broken in 64-bit >>XWin. >> >>Unfortunately, this is rather complex to fix and I haven't found the time to >>do so yet. > >Thank you for your reply. I've sent an RFU for keepassx along with a link to >your reply. If and when you tie the two clipboards together, keepassx should >just start working - there shouldn't be a need to rebuild it, but I'll do that >if necessary. This should be working as of xserver 1.14.1-2. Please test if you can and let me know if there are any problems. Thank you for implementing this functionality. I have tested xserver 1.14.1-2 and can confirm that this is working - keepassx can copy URLs, usernames and passwords into the Windows clipboard. Many thanks once again, Dave. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: cygwin and xwin and super and hyper
Jon TURNEY writes:
> On 19/06/2013 22:27, J. David Boyd wrote:
>> I can get my capslock key to be super with the command line 'setxkbmap
>> -option
>> caps:super', but I can't get 'setxkbmap -option altwin:hyper_win' to do
>> anything.
>>
>> Running 'setxkbmap -print' shows both options as being set, but the win keys
>> still act as the win key.
>>
>> Is there something else I need to do so windows lets go of these keys?
>
> Yes.
>
> Again, let me refer you to [1]. The operative sentence is:
>
>> (Note that mapping the Windows keys to hyper also requires the -keyhook
>> option, so that the X server sees those keys before the Windows shell)
>
> One thing I failed to mention there is that without any keymap options the
> keymap should give you super on the windows keys, but you will still need
> -keyhook X server option to enable the X server to see the key.
>
> [1] http://cygwin.com/ml/cygwin/2012-03/msg00427.html
I can get everything working up to the point I start emacs.
The output from 'setxkbmap -print' is:
xkb_keymap {
xkb_keycodes { include "xfree86+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat{ include "complete" };
xkb_symbols { include
"pc+us+inet(pc105)+altwin(alt_super_win)+capslock(hyper)" };
xkb_geometry { include "pc(pc105)" };
};
and if I run XEV, and press capslock I get:
KeyPress event, serial 32, synthetic NO, window 0xc1,
root 0x131, subw 0x0, time 8145997, (504,324), root:(2162,400),
state 0x0, keycode 66 (keysym 0xffed, Hyper_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 32, synthetic NO, window 0xc1,
root 0x131, subw 0x0, time 8146122, (504,324), root:(2162,400),
state 0x40, keycode 66 (keysym 0xffed, Hyper_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
and if I press Left Windows key I get:
KeyPress event, serial 32, synthetic NO, window 0xc1,
root 0x131, subw 0x0, time 8148993, (504,324), root:(2162,400),
state 0x0, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 32, synthetic NO, window 0xc1,
root 0x131, subw 0x0, time 8149102, (504,324), root:(2162,400),
state 0x40, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
All perfect so far.
So, when I start up emacs, and press C-h k, then, for example, Capslock-d,
(hyper-d) I get 'H-d is undefined'. Yeah.
Then I press C-h k, then Left-Win-d, (super-d), I get 'H-d is undefined', and
not 's-d is undefined', which is what I expected to see.
Any ideas how I might resolve this?
Dave
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: 64-bit Clipboard troubles
On 10/06/2013 22:39, David Stacey wrote: > On 10/06/13 14:30, Jon TURNEY wrote: >> On 09/06/2013 19:59, David Stacey wrote: >>> >I am trying to package keepassx for 64-bit Cygwin, and have noticed a >>> >difference between the way the clipboard functions under 32-bit and 64-bit >>> >Cygwin/X. Essentially, keepassx is an encrypted password database that >>> >copies your username and password to the clipboard. Then, you can paste >>> >these into a web site (say) to log in. >>> > >>> >When I run keepassx (both 32-bit and 64-bit builds) using the 32-bit >>> >version of XWin, keepassx copies the username and password to the >>> >clipboard, and these can be pasted into a native Windows web browser (e.g. >>> >Firefox). However, when I run keepassx (again, both 32-bit and 64-bit >>> >builds) using the 64-bit version of XWin, the procedure breaks: I instruct >>> >keepassx to copy to the clipboard, but when I paste in the web browser, no >>> >text is pasted. >> Sorry, integration between the native and X clipboards is broken in 64-bit >> XWin. >> >> Unfortunately, this is rather complex to fix and I haven't found the time to >> do so yet. > > Thank you for your reply. I've sent an RFU for keepassx along with a link to > your reply. If and when you tie the two clipboards together, keepassx should > just start working - there shouldn't be a need to rebuild it, but I'll do that > if necessary. This should be working as of xserver 1.14.1-2. Please test if you can and let me know if there are any problems. On 10/06/2013 14:30, Jon TURNEY wrote: >> I mentioned that my testcase programme doesn't quite work as I intended: >> > writing to the clipboard using Qt4 and reading it back by reading >> > /dev/clipboard fails when using both 32-bit and 64-bit XWin. I don't >> > understand why, but this is probably down to my own limited understanding >> > of the clipboard in X. > Thanks for writing this useful testcase. > > From a brief glance, the test looks well formed, so I'll also try to take a > look at why test 2 always fails, I guess this indicates some bug in the > clipboard integration. Looking again, I think maybe that the problem with test 2 is that it's necessary for Qt's main event loop to be running for pastes from the X clipboard to work. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: fltk / gl rendering problem
On 17/06/2013 07:48, marco atzeri wrote: > Il 6/16/2013 4:51 PM, marco atzeri ha scritto: >> testing a octave/fltk graphics issue, I noticed that also the >> demo of fltk with GL interface has a similar issue. Thanks for reporting this and thanks for providing the test binaries. >> On http://matzeri.altervista.org/works/fltk_gl/ >> I uploaded the before and after apperance of "gl_overlay" demo. >> >> It is enough to move the window to loose the geometrical >> image while the bars are correctly re-drawn. >> >> Running Xwin with -wgl does not show such defect, but it is >> terribly slow. So I assume it is not a fltk defect but of >> GL or XServer. I guess this should read "with -nowgl", in which case, this is a limitation of the current implementation of -wgl mode, which will require lots of work to fix. I wrote a bit about these limitations at [1] [1] http://www.cygwin.com/ml/cygwin-xfree/2012-10/msg9.html > further experiment showed that the defect is present when the integrate > windows manager is used. With external window manager (fvwm, openbox,.. ) that > defect does not apper. > > With external window manager another defect appears, the upper > bar effect is not shown at all; while it is present on the integrated > window manager. When I tested this, it looks like the solid area controlled by the "sides" slider didn't get rendered into a separate layer when using software rendering (either -nowgl or X server in windowed mode), so this is possibly some bug or limitation in the software renderer, or possibly in a bug in the demo not recognizing the lack of capabilities of the software renderer. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
