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?