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

["Daniel P. Berrange" <berrange redhat com>]

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. 

> >> 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.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|