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