Re: [gtk-vnc-devel] gtk-vnc trouble
- From: Anthony Liguori <anthony codemonkey ws>
- To: "Daniel P. Berrange" <berrange redhat com>
- Cc: gtk-vnc-devel <gtk-vnc-devel lists sourceforge net>
- Subject: Re: [gtk-vnc-devel] gtk-vnc trouble
- Date: Wed, 22 Aug 2007 11:03:00 -0500
On Wed, 2007-08-22 at 16:58 +0100, Daniel P. Berrange wrote:
> On Wed, Aug 22, 2007 at 05:43:43PM +0200, Gerd Hoffmann wrote:
> > Daniel P. Berrange wrote:
> > >> Number one and most annonying is the i18n keyboard problem. My app used
> > >> to simply send us keysyms unconditionally. Hackish, agreed. Worked
> > >> reasonable well though, with the exception of keys not presend on us
> > >> keyboards. Doesn't work any more as the keyboard handling is now in the
> > >> widget source ...
> > >
> > > Not sure what you mean by 'send keysyms unconditionally' ? Do you need an
> > > API for injecting fake keysyms to the widget ?
> > No. I had a hard-coded table "keycode -> us-map keysym" and used that
> > to send us keysyms to the vnc server no matter what keyboard mapping the
> > client machine has.
> In handling the keysyms we already redo the keycode -> keysym mapping
> because we need to mask out all the control keys except SHIFT, to let
> the server interpret them too. For this we call gdk_keymap_get_default()
> and then gdk_keymap_translate_keyboard_state(). Unfortunately it does
> not look like there's a way to get an arbitrary non-default keymap :-(
> I'm not too familiar with all the horrible details of keycode/keymaps
> wrt to VNC & virt, but sounds like a VNC extension for sending raw
> keycodes might be best approach, pushing off the translation proiblem to
> the remote end ?
> > >> Next problem is that the vnc_display_set_*_grab() functions seem to have
> > >> no effect. Any hints on that one?
> > >
> > > They ought to be working - the gvncviewer demo program uses them to control
> > > whether pointer grab occurs or not. The default is not to grab pointer or
> > > keyboard. Setting grab pointer, implies grab keyboard. It'll grab upon first
> > > pointer press. If merely doing keyboard grab it grab keyboard on mouse enter
> > > and ungrab on mouse leave of the widget.
> > I see it grab all the time and vnc_display_set_*_grab(widget, FALSE)
> > doesn't turn it off.
> Oooh - are you running against a QEMU vnc server perhaps ? QEMU supports
> a 'relative mouse' RFB protocol extension where the motion coords on the
> wire are treated as relative instead of absolute. It looks like we always
> enable support for that extension if the server accepts it. And if this
> is activated, then the pointer will be grabbed no matter what.
Yes, I think that should be the behavior too otherwise the extension
isn't terribly useful :-) It probably makes sense to be able to disable
the extension though.
> > >> Also vnc_display_open(), vnc_display_close(), then again
> > >> vnc_display_open() with the same widget instance doesn't work.
> > >
> > > Do you call the vnc_display_close & vnc_display_open immediately following
> > > each other, or does the mainloop run ? The close function does an asynchronous
> > > shutdown so the GTK mainloop needs to run before it'll actually die off.
> > mainloop runs inbetween due to user interaction being needed (there is a
> > "connect ..." menu entry).
> Ok that's odd - is your client app code around anywhere public to test with ?
] [Thread Prev