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

Bug#381979: (no subject)

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?


P.S. I'd be happy to discuss this further on IRC if you like.


Attachment: pgpcEYhte3yK5.pgp
Description: PGP signature

Reply to: