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