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? Cheers, FJP P.S. I'd be happy to discuss this further on IRC if you like. [1]http://mail.gnome.org/archives/gtk-devel-list/2006-September/msg00020.html
Attachment:
pgpcEYhte3yK5.pgp
Description: PGP signature