[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 [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.



Reply to: