On Mon, Jul 02, 2007, Attilio Fiandrotti wrote:
> The core of the problem is not detecting the keymap change at the toolkit
> level (which is unimportant in our case) but rather informing the windowing
> system (DirectFB in our case) that the keymap has to be updated to match
> the console one set by keymap-chooser (or whatever is the d-i component
> performing that task).
Well, s/toolkit/windowing system/: why not work on making the windowing
system aware of keymap changes rather than adding API to force a reload
manually?
> If we were on X, we could probably use setxkbmap to tell the X server
> the keymap had changed.
Hmm you could use setxkbmap to *change* the keymap of the server, and
you wouldn't have to do anything in each client. It's precisely
thinking of the X model that I was surprized you wanted to add API to
do more things manually, and it's only fixed at the toolkit level, for
this toolkit, instead of the lower levels.
> From within the cdebconf process, there is unluckily no easy way to
> detect / being informed that the console's keymap has changed.
> So, what we do is forcing, from the gtk frontend, keymap reloading at
> every frontend::go() call.
What channels could we use to inform directfb of keymap changes? Would
it be possible to make whatever first process controls the FB listen on
some agreed upon socket location and send some "the keymap has been
reloaded" messages to it when the relevant "change keymap" binary is
run? Or perhaps the kernel can send such events, as I understand it's
the layer where the switch happens?
> A reasonable improvement over current situation could prbably be setting
> TRUE a boolean "d-i/keymap_changed" question from within the keymap-chooser
> everytime the console keymap is updated.
> At every frontend_go() call, the gtk frontend should do something like
> (pseudocode)
>
> if ( question_get("d-i/keymap_changed") == TRUE ) {
> dfb_input_device_reload_keymap( dfb_input_device_at( DIDID_KEYBOARD ) );
> question_set ("d-i/keymap_changed", FALSE);
This would only work for debconf aware programs having this snippet and
if all keymap-changing programs are made debconf-aware too. The
advantage of a lower-level solution would be to enable this detection
for all situations.
IOW: how do keymap-changing programs inform the DirectFB layer that the
keymap has changed and it should reload it (transparently for any
higher layer)?
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
