Sorry about the previous message.
On Tue, 3 Dec 2002, Rodolphe Ortalo wrote: > [GGI folks may be interested by 2) below.] > > On Mon, 2 Dec 2002, Filip Spacek wrote: > [...] > > Thanks for the details. > > > So to answer your question: it depends on the number of focuses you have > > (which is equal to the number of keyboards) > > > > I usually replace display 0 with my driver (since I have only one card in > > my test box and I don't want kgi to think that there are two -- boot and > > the new driver, although this still need a bit of work so that the > > consoles get migrated properly) in which case my /dev/graphic has minor 1 > > since I'm working with device 0 which gets mapped to display 0. If you > > have only one keyboard and like to replace display 1 with your driver then > > for instance minor number 5 would make sense as that maps to device 4 > > which maps to display 1. > > I usually have minor 16 in place (works for display=3). > I've tried with minor 5, indeed, then graphical libggi applications work > while loading the module with display=1 (and I can also start additional > VGA text consoles on the secondary monitor) however, the overall behavior > is exactly the same: > - some applications successfully get input (flying_ggis, stars, > etc.) *if* no switch-away is done. > - other applications never get any input (monitest, etc.) > > So: > > 1) I still don't know how to switch to the "graphical console" once > opened. It gets given some device id (like 79 for display=3, 68 for > display=1), surely a kii->id in that case. However, any ALT-Fx combination > requests a device id between 0 and 11, and ALTGR-Fx between 12 and 15 or > an invalid one (255) - it is surely a console device id in this case > (event.c?). > I wonder if there is not some "mis-understanding" between event.c and > kii.c wrt to these differents ids (console and kii), during the management > of the "console switch" (kernel-internal) events. (I've also tried the > INCRCONSOLE or DECRCONSOLE things.) > Note also that, when an input-responsive application terminates normally, > I do *not* get switched back to the initial console (but this may be > normal as it is on another head so, conceptually, the focus is associated > to nothing). This seems like an error in your keymap. KGI has 64 console devices (devices 0-63) and 64 graphic devices (devices 64-127). In order to switch to the graphic device you must bind your ALTGR-Fx to switch to device x+64. Now, I could swear the default kgi keymap already does that, but it doesn't seem to be the case for you. Anyways, your keymap should have Console_x for ALT-Fx and Graphic_x for ALTGR-Fx (loadkeys apparently already behaves exactly the way kgi does, i.e. the symbol Graphic_x means console x+64). > 2) some GII applications get some input, some never get input. I've > activated kii.c DEBUG_LEVEL and I can actually see the input key > events being queued (before I switch away [1]) for all > applications. Setting GII_INPUT=128 shows some astonishing behavior (IMO). > With, e.g., "flying_ggis", I get continuous messages "giiEventPoll: > starting non-polled loop", followed by "giiEventPoll(...): called", > followed by "_giiPollAll(...,...,(nil)): called". These messages repeat in > a _continuous_ loop, until I hit a key, then they reappear until I hit > 'q'. > With, e.g., "monitest", I get some "called" messages, then a _single_ > "giiEventPoll: starting non-polled loop" and then the process gets > blocked indefinitely (even if I hit some key). > Astonishingly, in some sense it seems to me that the second behavior may > be _more_ sensible: when I do not hit any key on the keyboard, I guess > giiEvenPoll() should not return (in non-poll mode) like it does for the > "flying_ggis" case. So maybe the problem is in the way KII signal that > some data is available to the calling process on /dev/event? Well, that's > just a guess - in fact I do not really understand what happens, it's just > I'm not very happy with it. I'd really like to see what that > "2)Convergence" option does (and no, I won't start X to see! :-). > > Rodolphe > > [1] As I have two screens, I can actually see the output log while typing > for another screen... :-) Anyway, kern.log confirms the queuing made by > event_handle_event() (event.c, l.444). > Ah. Well, I probably should have mentioned this before, but do not assume the kii target for libgii is correct. If something doesn't work, there's better chance that it's the target being wrong rather than you doing something wrong :-) (I haven't tested it extensively either, just played ggidoom for a bit) I think I have seen something like you describe. In certain applications, bashing the keyboard long enough will eventually overrun the /dev/event buffer indicating that obviously something isn't getting polled right. I would very much like if somebody who understands libgii more than I do could look at the kii target and see where did I screw up there. -Filip
