Bug#381979: (no subject)
Frans Pop wrote:
On Sunday 10 September 2006 10:51, Attilio Fiandrotti wrote:
After posting on gtk-devel, i received some answers  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 ? 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.