Re: [gtk-vnc-devel] gtk-vnc trouble

[Anthony Liguori <anthony codemonkey ws>]

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.

Regards,

Anthony Liguori

> > >> 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 ?
> 
> Dan.