Frans Pop wrote:
On Sunday 10 September 2006 10:51, Attilio Fiandrotti wrote:
After posting on gtk-devel, i received some answers [1] from DFB's main
developer and GTKDFB original author, but it seems nothing is going to
be done to add the needed functionality at the lower GDK or DFB level,
so i propose to apply this patch as a temporary workaround.
Also discussed with Davide yesterday :-)
Do I understand correctly that there are two issues:
1. the kernel keymap needs to be reloaded when kbd-chooser changes it;
2. the running directfb instance for the main menu needs to be "told"
to use the reloaded keymap.
IIUC the attempts Davide and I did before my holidays using 'dfbinput -r'
did not work because they did 1, but not 2.
From the messages on VT2 (or syslog if run from the postinst script) it
looks like probably a new dfb instance is started instead of the current
one used (which would explain why the frontend does not respond to it).
Comparing the output of 'dfbinput -k' however does show that the keymaps
really are different!
Your patch effectively combines 1 and 2 by always reloading the keymap
whenever a new display is built.
As a temporary solution your patch may be acceptable, but as you said
yourself, it is not very clean.
How much work would a real solution be where kbd-chooser (which is a C
program!) could somehow signal the frontend that the keymap has changed?
It should be trivial to run 'dfbinput -r' from kbd-chooser. But what
exactly does 'dfbinput -r' do? Does that somehow signal apps that they
should also change the keymap, just as described for X in [1]? Is picking
up the signal what is missing in the frontend?
Or do we need a smarter version of dfbinput that knows how to hook into
the existing dfb instance?
IIUC what dok said, "dfbinput -r" does not work in the specific case of
the g-i because, AFAIK, DirectFB udebs are built without the multicore
support, so every DFB process has so take care of reloading the keymap
by itself, as needed.
Making kbd-chooser able to tell the GTK frontend to reload the keymap
via unix signal can be done, but reloading the keymap at every
frontend_go() call (exactly like i did with gtk_rc_reparse_all() ) is
easier and causes no overhead.
So, i'm for the easy option, as this requires to touch a single package
(cdebconf only and not localechooser) and, as a temporary workaround,
this will be easier to revers when possible.
cheers
Attilio
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]