Loïc Minier wrote:
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?
Well, neither X is able nor supposed, AFAIK, to detect console keymap
changes and set its keymap accordingly, it has to be told from external
by means of setxkbmap..
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.
As i said before, if we had multiapp support in our DirectFB builds, we
could implement a setxkbmap-like mechanism with DFB, but since we don't,
i was thinking about that from-toolkit-level hack to force keymap
reloading, which i now see it's not a good solution after all..
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?
Because it's difficult, without multiapp support, telling the directfb
master application (cdebconf, in the case) to reload keymap from
external, then it's better having cdebconf listening on a dedicated
channel (a debconf question, a socket, a pipe.. ) for the update to happen.
I guess the "reload-keymap" signal must be sent at the application
level, namely from the application that manages keymap changes in d-i.
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.
That's correct, but ATM only d-i requires keymap updates.
If we were using cdebconf as a debconf replacement, i doubt such a
necessity would arise.
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)?
ATM, there is no such mechanism: at every frontend::go() call the GTK
frontend forces DFB to reload keymap, no matter the update was realy
necessary or not, hence the pollution in cdebconf's output :(
regards
Attilio
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
